created PDF block include and logic to include it in the section subm…

…enu if site_section contains 'cck'. Pages in the CCK section may now include the Download PDF button and Download All button by using two front matter variables: 'pdf: pdf-filename-in-files-directory' and 'pdf-all: true'

test.commotion/_includes/cck_download_pdfs_block.html

@@ -0,0 +1,16 @@
+{% if {{page.pdf}} %} 
+<div class="cck-download-pdf">
+  <a href="/files/{{page.pdf}}">
+  <img src="/files/CCK_pdf.png" alt="Download {{page.title}} PDF" /">
+  </a>
+</div>
+<span class="cck-download"><a href="/files/{{page.pdf}}">Download PDF</a></span>
+{% endif %}
+{% if {{page.pdf-all}} %}
+<div class="cck-download-all">
+  <a href="/files/cck-1.0.zip">
+  <img src="/files/CCK_allpdf.png" alt="Download All CCK Modules as PDFs" /><br />
+  <span class="cck-download">Download All</span>
+  </a>
+</div>
+{% endif %}

test.commotion/_includes/sub-sections-menu.html

@@ -11,3 +11,6 @@
 {% include developers_menu.html %}
 {% else %}
 {% endcase %}
+{% if page.sub_section contains 'cck' %}
+{% include cck_download_pdfs_block.html %}
+{% endif %}

test.commotion/_site/about/faq/index.html

@@ -127,6 +127,7 @@ <h3><a href="/about">About</a></h3>
 
 
 
+
 </div>
 
 <div class="left-twothird">

test.commotion/_site/about/guiding-principles/index.html

@@ -127,6 +127,7 @@ <h3><a href="/about">About</a></h3>
 
 
 
+
 </div>
 
 <div class="left-twothird">

test.commotion/_site/about/index.html

@@ -127,6 +127,7 @@ <h3><a href="/about">About</a></h3>
 
 
 
+
 </div>
 
 <div class="left-twothird">

test.commotion/_site/about/license-privacy/index.html

@@ -127,6 +127,7 @@ <h3><a href="/about">About</a></h3>
 
 
 
+
 </div>
 
 <div class="left-twothird">

test.commotion/_site/about/press/index.html

@@ -127,6 +127,7 @@ <h3><a href="/about">About</a></h3>
 
 
 
+
 </div>
 
 <div class="left-twothird">

test.commotion/_site/about/where-its-used/index.html

@@ -127,6 +127,7 @@ <h3><a href="/about">About</a></h3>
 
 
 
+
 </div>
 
 <div class="left-twothird">

test.commotion/_site/access-denied/index.html

@@ -113,6 +113,7 @@ <h1 class="pageheadings">Access Denied</h1>
 
 
 
+
 </div>
 
 <div class="left-twothird">

test.commotion/_site/blog/2012/05/01/integrating-design-and-development-shape-commotion’s-brand-identity/index.html

@@ -703,13 +703,13 @@ <h2 class="blog-pubdata">2012-05-01 / The Work Department</h2>
 <p>You can view our <a href='https://code.commotionwireless.net/attachments/download/122/Commotion%20Identity%20Proposals.pdf'>Commotion Identity Proposals here</a>. OTI staff chose the final direction for the identity and we created complete <a href='/sites/kb.commotionwireless.net/files/Commotion%20Brand.pdf'>brand identity guidelines</a>. We’re proud to be an integral part of the Commotion project and excited about OTI’s commitment to good design. While other mesh network projects have not created a professional identity, Commotion is being built on a strong foundation of flexible and collaborative design that can be used by all the developers who work on it. This will create lasting consistency and credibility among users, developers, and funders. As designers, this has been a unique opportunity to be involved early in a software development process (instead of at the tail end). We’ve worked with Commotion’s software developers throughout our process. Thanks to this, and our previous experience working on community wireless tools, we are able to significantly inform how the open source development process moves forward. It’s rare that a project takes such an integrated approach – bringing designers and developers together each step of the way. We love working this way, and think that this approach should be used more often. It allows us to ultimately create a better product together – a software tool that offers an outstanding user interface, is credible, is easy to use, and is flexible enough to evolve around the world but maintain a core set of functions and standards. We’re convinced that any software project that integrates designers, developers, and user interface thinkers is far more likely to succeed over the long-term. We’re excited to soon release graphic assets for the Commotion Brand Identity. These files will be publicly available in just a few weeks – check back here for updates!</p>
  <h4>Tags:</h4>
 
- <a href="/blog/blogindex#ui">ui</a>&nbsp;
+ <a href="/blog/blogindex.html#ui">ui</a>&nbsp;
 
- <a href="/blog/blogindex#branding">branding</a>&nbsp;
+ <a href="/blog/blogindex.html#branding">branding</a>&nbsp;
 
- <a href="/blog/blogindex#identity">identity</a>&nbsp;
+ <a href="/blog/blogindex.html#identity">identity</a>&nbsp;
 
- <a href="/blog/blogindex#research">research</a>&nbsp;
+ <a href="/blog/blogindex.html#research">research</a>&nbsp;
 
 
     </div>

test.commotion/_site/blog/2012/05/08/neighborhood-network-builders-summary/index.html

@@ -703,15 +703,15 @@ <h2 class="blog-pubdata">2012-05-08 / The Work Department</h2>
 <p>&lt;/div&gt;</p>
  <h4>Tags:</h4>
 
- <a href="/blog/blogindex#ui">ui</a>&nbsp;
+ <a href="/blog/blogindex.html#ui">ui</a>&nbsp;
 
- <a href="/blog/blogindex#detroit">detroit</a>&nbsp;
+ <a href="/blog/blogindex.html#detroit">detroit</a>&nbsp;
 
- <a href="/blog/blogindex#community wireless">community wireless</a>&nbsp;
+ <a href="/blog/blogindex.html#community wireless">community wireless</a>&nbsp;
 
- <a href="/blog/blogindex#research">research</a>&nbsp;
+ <a href="/blog/blogindex.html#research">research</a>&nbsp;
 
- <a href="/blog/blogindex#recommendations">recommendations</a>&nbsp;
+ <a href="/blog/blogindex.html#recommendations">recommendations</a>&nbsp;
 
 
     </div>

test.commotion/_site/blog/2012/05/09/audit-current-commotion-user-interfaces/index.html

@@ -718,11 +718,11 @@ <h4>4. Connectivity and configuration validation</h4>
 <p>Finally, we recommend a positive message, sound or validation feature when the network has been successfully configured and instructions on what to do next. As of now, the user is just left to assume (or not) that the settings they have entered are valid. A progress wheel, or something similar, is also recommended where appropriate, as it gives the user a sense of progress when going through the installation and configuration process. An example can be found with the OLSR Mesh Tether device error message. The message told us that the device needed to be rooted in order to proceed, but with little experience in development for handheld devices, a user will not be familiar with what the term “root” means and will be left with no pathway to move forward.</p>
  <h4>Tags:</h4>
 
- <a href="/blog/blogindex#ui">ui</a>&nbsp;
+ <a href="/blog/blogindex.html#ui">ui</a>&nbsp;
 
- <a href="/blog/blogindex#ux">ux</a>&nbsp;
+ <a href="/blog/blogindex.html#ux">ux</a>&nbsp;
 
- <a href="/blog/blogindex#research">research</a>&nbsp;
+ <a href="/blog/blogindex.html#research">research</a>&nbsp;
 
 
     </div>

test.commotion/_site/blog/2012/05/30/building-successful-online-community-open-source-development/index.html

@@ -701,9 +701,9 @@ <h2 class="blog-pubdata">2012-05-30 / The Work Department</h2>
 <p> <strong>Open Governance</strong> In order to promote long-term investment and encourage a wide array of contributors to get involved, we recommend that OTI establish a clear and written governance structure for the Commotion project. This should include roles of various people in the community and general expectations for how contributors should work together and make key decisions. Many examples are available from other projects. The governance structure should be posted on the Commotion site and be recommended reading for all newcomers to the project. This will help contributors understand how they can be involved and how their work will be valued. <strong>Future Considerations</strong> Translation and other localization work should be planned at an appropriate time in the future. The communities that we evaluated each have specific areas of their sites dedicated to localization efforts. This is also a good opportunity for non-programmers to contribute to the project. <strong>Want more?</strong> <a href='https://code.commotionwireless.net/projects/knowledgebase/wiki/Report_-_Building_successful_online_community_for_open-source_development' target='blank'>Read our full report at the Commotion wiki</a>.</p>
  <h4>Tags:</h4>
 
- <a href="/blog/blogindex#recommendations">recommendations</a>&nbsp;
+ <a href="/blog/blogindex.html#recommendations">recommendations</a>&nbsp;
 
- <a href="/blog/blogindex#research">research</a>&nbsp;
+ <a href="/blog/blogindex.html#research">research</a>&nbsp;
 
 
     </div>

test.commotion/_site/blog/2012/08/22/exploring-meshaging/index.html

@@ -699,9 +699,9 @@ <h2 class="blog-pubdata">2012-08-22 / The Work Department</h2>
 <p>Over the past few years, The Work Department has been active in building community wireless networks in Detroit. We have experimented with different types of hardware and software, and we have helped neighborhoods build useful networks to share internet connectivity and provide local file sharing. Something we haven’t had much of an opportunity to explore, though, is building more elaborate systems that leverage the unique traits of mesh networks. As we worked through other parts of the Commotion project, we brainstormed ideas for wireless mesh applications. We noticed that our ideas would often replicate existing web services — e.g. a local fileserver for music or movies, or a local message board for neighborhood discussion. We began to wonder what would make a community wireless application more appealing than using a centralized Internet-based application. We agreed that it wouldn’t be enough to offer someone the simple satisfaction of knowing their data is decentralized… there would need to be some other benefits to using a local application. What would these benefits be? What is special about the architecture of a community wireless mesh network? In pondering these questions, we considered what is provided by these networks — earlier, I mentioned that the networks provide internet connection sharing and local file sharing, but that’s only a part of the story. These networks also provide something much grander: they become community institutions. Unlike the Comcast hardware that is bolted out of arm’s reach on a utility pole, our community wireless equipment lives on our porches, in chicken coops, in our bell towers, and next to our desks. Each piece of equipment has a story behind it. We know who held the ladder while it was being installed and who lent their hammer drill to run a cable up to it. A community mesh wireless router’s IP address is more than a 32-bit number. It has history and meaning. How can we build applications that reflect and enhance this? I had the good fortune to meet Adam Magaluk at Detroit’s hackerspace, OmniCorpDetroit. Adam works on mesh wireless systems at Illuminating Concepts, and is deeply interested in OLSR and embedded systems. We are both young programmers and share a preference for modular and decentralized systems. During our initial conversations and research, we ended up favoring web browser based application development. This way, people who might want to use an application wouldn’t have to download anything. Since today’s web browsers have lightweight streaming messaging capabilities with WebSocket, we would have a lot of flexibility in application development. To build a web browser based application, we can start by limiting the amount of work the server does to a bare minimum. In the circumstance of a chat application, we can say that the server should simply keep a record of who is connected to a chat session (in a sort of subscription model) and then, as messages are posted, transfer messages from the publisher to the subscribers. Limiting the duties of each mesh node to passing messages and keeping track of connected clients ends up being beneficial in two ways: it conserves computing resources and encourages decentralized application development. Since most community wireless routers are low power, low cost devices running with MIPS CPUs and 4-16GB memory, the former benefit is clearly attractive. The latter benefit is a bit more complex — do we really need a fully decentralized application? Why can’t we just have a little bit of local node storage? It sure would make things simpler if we could have a local data cache instead of trying to develop a peer-to-peer storage system, but for now we’ll embrace this limitation when designing applications. To begin experimenting with the core concepts of lightweight messaging systems that can work with community wireless network hardware, we built an example application to provide WebSocket service to clients connected to a Commotion access point. This service can be utilized by anything on the network, but in our first example application, it is employed by a web application served from a publicly accessible LuCI URI linked from the splash page. The application provides a simple interface to chat with other people who have connected to the local node’s websocket chat system. Thanks to the work of Hans-Christoph Steiner (from <a href='https://guardianproject.info/' target='_blank'>The Guardian Project</a>) on the jsoninfo plugin, OLSRd can easily provide some useful network information as a json object to web applications. Above the network layer, our WebSocket message server can provide data about connected clients and possibly other information in the future. After you get your head wrapped around the WebSocket server, its underlying restrictions, and the mesh network playing field, you can start to imagine various situations where local messaging might be interesting. With an idea in mind, a developer can easily jump into a familiar web application development environment. If you have used things like WebSockets or socket.io, you already understand the core concepts of writing a mesh network application using these building blocks. As we build more features into the platform, it will offer more options for developers. <strong>Next Steps</strong> Currently, the system provides a messaging service that doesn’t utilize node-to-node mesh connections. As it stands, we can develop some interesting and useful applications, but there is definitely a lot to gain from adding functionality and possibly revamping things in the interest of security or privacy. Our next major task is to begin experimenting with systems that- allow neighboring nodes to subscribe to each others’ connections. To use the chat application as an example of how this might be used: a chat participant might be able to start a conversation with people connected to their own mesh node and its next neighbors, or some other arbitrary number of hops. We would also like to experiment with simple implementations of shared / distributed storage. Again, to use the chat system as an illustration, we could have chat participants store chat logs and offer them to new participants who broadcast a request for the last N minutes of conversation. There is a lot of distributed storage work for us to reference, of course, so we have our work cut out for us! Aside f/rom enhancements and features in the messaging system itself, we have plenty of ideas for the actual applications. We have recently been prototyping games that could use a neighborhood or multi-neighborhood mesh network as a playing field. We have found that prototyping and brainstorming games is an enlightening process: it helps explain the ins and outs of the technology to people, and also presents clear challenges to create obvious and attainable goals within the technology’s limitations. We’ll be sharing some “capture the flag” style game ideas that utilize a “meshaging” system during the next couple of weeks.</p>
  <h4>Tags:</h4>
 
- <a href="/blog/blogindex#messaging">messaging</a>&nbsp;
+ <a href="/blog/blogindex.html#messaging">messaging</a>&nbsp;
 
- <a href="/blog/blogindex#detroit">detroit</a>&nbsp;
+ <a href="/blog/blogindex.html#detroit">detroit</a>&nbsp;
 
 
     </div>