From 52207e55c733917bedd038003174b52813f61554 Mon Sep 17 00:00:00 2001 From: Chris Ritzo Date: Tue, 25 Feb 2014 13:56:32 -0500 Subject: [PATCH] created PDF block include and logic to include it in the section submenu 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' --- .../_includes/cck_download_pdfs_block.html | 16 ++++++++++++ .../_includes/sub-sections-menu.html | 3 +++ test.commotion/_site/about/faq/index.html | 1 + .../_site/about/guiding-principles/index.html | 1 + test.commotion/_site/about/index.html | 1 + .../_site/about/license-privacy/index.html | 1 + test.commotion/_site/about/press/index.html | 1 + .../_site/about/where-its-used/index.html | 1 + test.commotion/_site/access-denied/index.html | 1 + .../index.html" | 8 +++--- .../index.html | 10 ++++---- .../index.html | 6 ++--- .../index.html | 4 +-- .../2012/08/22/exploring-meshaging/index.html | 4 +-- .../_site/blog/2012/09/19/making/index.html | 4 +-- .../10/08/diving-deeper-meshaging/index.html | 8 +++--- .../index.html | 8 +++--- .../01/updating-commotion-package/index.html | 8 +++--- .../index.html | 6 ++--- .../2012/11/14/cost-mesh-networks/index.html | 8 +++--- .../index.html | 14 +++++------ .../index.html | 14 +++++------ .../index.html | 12 ++++----- .../index.html | 12 ++++----- .../index.html | 8 +++--- .../index.html | 12 ++++----- .../index.html | 2 +- .../index.html | 10 ++++---- .../index.html | 14 +++++------ .../index.html | 4 +-- .../index.html | 4 +-- .../index.html | 10 ++++---- .../index.html | 14 +++++------ .../19/commotion-dr2-release-notes/index.html | 2 +- .../index.html | 12 ++++----- .../building-popup-mesh-networks/index.html | 4 +-- .../index.html | 6 ++--- .../index.html | 2 +- .../commotion-r1-breaking-changes/index.html | 4 +-- .../index.html | 6 ++--- test.commotion/_site/chat/index.html | 1 + .../_site/content/about-commotion/index.html | 1 + .../content/commotion-10-released/index.html | 1 + .../_site/content/get-involved/index.html | 1 + .../_site/content/get-started/index.html | 1 + .../questions-about-commotion/index.html | 1 + test.commotion/_site/css/commotion.css | 25 +++++++++++++++++++ .../hig/design-principles/index.html | 1 + .../_site/developer/hig/downloads/index.html | 1 + .../developer/hig/introduction/index.html | 1 + .../developer/hig/key-concepts/index.html | 1 + .../developer/hig/key-processes/index.html | 1 + .../_site/developer/hig/style/index.html | 1 + .../hig/updating-guidelines/index.html | 1 + .../_site/developer/resources/index.html | 1 + .../grounding-lightning-protection/index.html | 1 + .../docs/build/roof-mount-guide/index.html | 1 + .../index.html | 5 ++++ .../docs/cck/building-mounting/index.html | 5 ++++ .../learn-about-rooftop-mounts/index.html | 5 ++++ .../learn-rooftop-basics/index.html | 5 ++++ .../prep-install-rooftop-nodes/index.html | 5 ++++ test.commotion/_site/docs/cck/index.html | 5 ++++ .../common-configuration/index.html | 5 ++++ .../configure-commotion/index.html | 5 ++++ .../cck/installing-configuring/index.html | 5 ++++ .../install-and-recover-tftp/index.html | 5 ++++ .../install-ubiquiti-router/index.html | 5 ++++ .../index.html | 5 ++++ .../_site/docs/cck/networking/index.html | 5 ++++ .../cck/networking/intro-to-mesh/index.html | 5 ++++ .../learn-networking-basics/index.html | 5 ++++ .../index.html | 5 ++++ .../index.html | 19 ++++++++++++++ .../get-word-out-flyer-design/index.html | 5 ++++ .../identify-neighborhood-skills/index.html | 5 ++++ .../_site/docs/cck/planning/index.html | 12 +++++++++ .../inventory-the-neighborhood/index.html | 5 ++++ .../planning/survey-your-neighbors/index.html | 5 ++++ .../planning/wireless-challenges/index.html | 5 ++++ .../_site/docs/get-involved/index.html | 1 + .../_site/docs/get-started/index.html | 1 + test.commotion/_site/docs/hig/index.html | 1 + test.commotion/_site/docs/index.html | 1 + .../_site/docs/localization/index.html | 1 + .../_site/docs/supported-devices/index.html | 1 + .../download-commotion-client/index.html | 1 + test.commotion/_site/download/index.html | 1 + .../download/openwrt/ubiquiti/index.html | 1 + .../download/verify-signatures/index.html | 1 + test.commotion/_site/help/connect/index.html | 1 + .../_site/help/questions/index.html | 1 + test.commotion/_site/jobs/index.html | 1 + test.commotion/_site/non-front.html | 1 + test.commotion/_site/osmobts/index.html | 1 + .../index.html | 1 + test.commotion/css/commotion.css | 25 +++++++++++++++++++ .../index.md | 2 ++ test.commotion/docs/cck/planning/index.md | 1 + 99 files changed, 367 insertions(+), 120 deletions(-) create mode 100644 test.commotion/_includes/cck_download_pdfs_block.html diff --git a/test.commotion/_includes/cck_download_pdfs_block.html b/test.commotion/_includes/cck_download_pdfs_block.html new file mode 100644 index 00000000..1e32a630 --- /dev/null +++ b/test.commotion/_includes/cck_download_pdfs_block.html @@ -0,0 +1,16 @@ +{% if {{page.pdf}} %} +
+ + Download {{page.title}} PDF + +
+Download PDF +{% endif %} +{% if {{page.pdf-all}} %} +
+ + Download All CCK Modules as PDFs
+ Download All + +
+{% endif %} diff --git a/test.commotion/_includes/sub-sections-menu.html b/test.commotion/_includes/sub-sections-menu.html index 777627cb..1168e5ac 100644 --- a/test.commotion/_includes/sub-sections-menu.html +++ b/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 %} diff --git a/test.commotion/_site/about/faq/index.html b/test.commotion/_site/about/faq/index.html index f523257f..b584a834 100644 --- a/test.commotion/_site/about/faq/index.html +++ b/test.commotion/_site/about/faq/index.html @@ -127,6 +127,7 @@

About

+
diff --git a/test.commotion/_site/about/guiding-principles/index.html b/test.commotion/_site/about/guiding-principles/index.html index 4d7aafc2..fbe004db 100644 --- a/test.commotion/_site/about/guiding-principles/index.html +++ b/test.commotion/_site/about/guiding-principles/index.html @@ -127,6 +127,7 @@

About

+
diff --git a/test.commotion/_site/about/index.html b/test.commotion/_site/about/index.html index 51baf814..7c4b5c63 100644 --- a/test.commotion/_site/about/index.html +++ b/test.commotion/_site/about/index.html @@ -127,6 +127,7 @@

About

+
diff --git a/test.commotion/_site/about/license-privacy/index.html b/test.commotion/_site/about/license-privacy/index.html index 3de25a53..8a99b2a3 100644 --- a/test.commotion/_site/about/license-privacy/index.html +++ b/test.commotion/_site/about/license-privacy/index.html @@ -127,6 +127,7 @@

About

+
diff --git a/test.commotion/_site/about/press/index.html b/test.commotion/_site/about/press/index.html index c617c5d4..2f0e7ad3 100644 --- a/test.commotion/_site/about/press/index.html +++ b/test.commotion/_site/about/press/index.html @@ -127,6 +127,7 @@

About

+
diff --git a/test.commotion/_site/about/where-its-used/index.html b/test.commotion/_site/about/where-its-used/index.html index 060dbf95..598eda4a 100644 --- a/test.commotion/_site/about/where-its-used/index.html +++ b/test.commotion/_site/about/where-its-used/index.html @@ -127,6 +127,7 @@

About

+
diff --git a/test.commotion/_site/access-denied/index.html b/test.commotion/_site/access-denied/index.html index 69627cd3..0e9ff6a7 100644 --- a/test.commotion/_site/access-denied/index.html +++ b/test.commotion/_site/access-denied/index.html @@ -113,6 +113,7 @@

Access Denied

+
diff --git "a/test.commotion/_site/blog/2012/05/01/integrating-design-and-development-shape-commotion\342\200\231s-brand-identity/index.html" "b/test.commotion/_site/blog/2012/05/01/integrating-design-and-development-shape-commotion\342\200\231s-brand-identity/index.html" index 53019956..9f1afba7 100644 --- "a/test.commotion/_site/blog/2012/05/01/integrating-design-and-development-shape-commotion\342\200\231s-brand-identity/index.html" +++ "b/test.commotion/_site/blog/2012/05/01/integrating-design-and-development-shape-commotion\342\200\231s-brand-identity/index.html" @@ -703,13 +703,13 @@

2012-05-01 / The Work Department

You can view our Commotion Identity Proposals here. OTI staff chose the final direction for the identity and we created complete brand identity guidelines. 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!

Tags:

- ui  + ui  - branding  + branding  - identity  + identity  - research  + research 
diff --git a/test.commotion/_site/blog/2012/05/08/neighborhood-network-builders-summary/index.html b/test.commotion/_site/blog/2012/05/08/neighborhood-network-builders-summary/index.html index e8e580ea..6b577be6 100644 --- a/test.commotion/_site/blog/2012/05/08/neighborhood-network-builders-summary/index.html +++ b/test.commotion/_site/blog/2012/05/08/neighborhood-network-builders-summary/index.html @@ -703,15 +703,15 @@

2012-05-08 / The Work Department

</div>

Tags:

- ui  + ui  - detroit  + detroit  - community wireless  + community wireless  - research  + research  - recommendations  + recommendations  diff --git a/test.commotion/_site/blog/2012/05/09/audit-current-commotion-user-interfaces/index.html b/test.commotion/_site/blog/2012/05/09/audit-current-commotion-user-interfaces/index.html index e9e5af4b..52ebac78 100644 --- a/test.commotion/_site/blog/2012/05/09/audit-current-commotion-user-interfaces/index.html +++ b/test.commotion/_site/blog/2012/05/09/audit-current-commotion-user-interfaces/index.html @@ -718,11 +718,11 @@

4. Connectivity and configuration validation

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.

Tags:

- ui  + ui  - ux  + ux  - research  + research  diff --git a/test.commotion/_site/blog/2012/05/30/building-successful-online-community-open-source-development/index.html b/test.commotion/_site/blog/2012/05/30/building-successful-online-community-open-source-development/index.html index a50f4f65..06347aea 100644 --- a/test.commotion/_site/blog/2012/05/30/building-successful-online-community-open-source-development/index.html +++ b/test.commotion/_site/blog/2012/05/30/building-successful-online-community-open-source-development/index.html @@ -701,9 +701,9 @@

2012-05-30 / The Work Department

Open Governance 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. Future Considerations 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. Want more? Read our full report at the Commotion wiki.

Tags:

- recommendations  + recommendations  - research  + research  diff --git a/test.commotion/_site/blog/2012/08/22/exploring-meshaging/index.html b/test.commotion/_site/blog/2012/08/22/exploring-meshaging/index.html index 997afd66..437cfebb 100644 --- a/test.commotion/_site/blog/2012/08/22/exploring-meshaging/index.html +++ b/test.commotion/_site/blog/2012/08/22/exploring-meshaging/index.html @@ -699,9 +699,9 @@

2012-08-22 / The Work Department

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 The Guardian Project) 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. Next Steps 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.

Tags:

- messaging  + messaging  - detroit  + detroit  diff --git a/test.commotion/_site/blog/2012/09/19/making/index.html b/test.commotion/_site/blog/2012/09/19/making/index.html index 1bf2018f..f7b7cc62 100644 --- a/test.commotion/_site/blog/2012/09/19/making/index.html +++ b/test.commotion/_site/blog/2012/09/19/making/index.html @@ -699,9 +699,9 @@

2012-09-19 / The Work Department

This site has been in the making for months and we’re excited to share it with the public! It’s intended to be the online home for the Commotion project — connecting both developers and users to mesh networking tools. We’ve been working with the Open Technology Institute (OTI) and the Commotion community of developers for over a year and this marks a major milestone in our collaborative relationship. Many steps have brought us to this point and many minds have contributed to the process. We’d like to share those key steps with you. Creating the brand identity In May we finished the brand identity for Commotion, which has informed all of our work to date. The versatile and accessible identity (a complete set of logos, typefaces, colors, usage standards, and language) was created for use in multiple environments — online, in print, on mobile phones, and in software. It’s important to us that people experience the Commotion identity consistently, no matter how they are interacting with the project. So, for those of you who have been following Commotion, the look and feel of this website should be no surprise. It adheres well to the brand identity and gives us an opportunity to demonstrate how to implement the identity and expand the visual palette — in a very public and ready-to-use way. Conducting user research We include user research in our planning and design process whenever possible because it’s essential to know what the actual users and surrounding community are thinking. In the early stages of the project, we conducted simple surveys among the Commotion community. Deeper into the process we conducted interviews with four users who were working with neighborhood mesh networks being used as testbeds for Commotion. This research shed some light on how people thought about Commotion, how users actually experienced its early software tools, and what common problems users were facing. This new knowledge informed how we organized the site to speak to two major audiences: developers and end users of the software. Dreaming of user interfaces We spent time prototyping user interfaces and developing Human Interface Guidelines (which are a set of recommendations for developers) with the useful input of many people in the Commotion community. This helped us build a visual framework for Commotion’s user experience and begin to set some standards for how the tools will work across multiple platforms. We established visual languages (descriptive, action, learning, warning, and in-progress languages) that carry through to this website. By interacting with other developers and designers during this “dreaming” stage, we incorporated more ideas and eventually settled on Human Interface Guidelines that meet the community’s needs. Researching other communities There are many successful open-source software projects out there, and it was important to take a look at their structures so we could learn from others and find out what we could improve on. We produced a brief report about four different open-source software communities, which is available here. We compared documentation, support, issue tracking, and governance systems, among others, for each community. This research provided a good overview of what systems were available and widely used. It informed how we structured this site, especially the home page. Drafting designs We started our website design process by creating a sitemap and set of wireframes to outline the navigational structure and content. We went through several iterations (over the course of a few weeks) based on feedback from Commotion developers and OTI staff members. Once this was complete, we began drafting designs for the home page and a few interior pages. We went through a similar revision process with OTI and created several iterations before coming to a final version which is the site you see today. The home page is the primary way in which we invite two different audiences to find what's relevant to them — new visitors and returning visitors. Because Commotion is such a young project and because the public has little experience with mesh networking, we wanted to create an easy introduction to the project while allowing returning visitors to access the main navigation menu. The details This site is run on Drupal and the Omega base theme. It is responsive to browser size (try changing the size of your browser!) and has been built with visual accessibility in mind (with sufficient contrast and without relying on color coding). It makes frequent use of the Context, Media, Panels, Wikitools, and Book modules in Drupal. Using Drupal’s basic role distinctions, different areas of the site will eventually be edited by different teams or staff members as the Commotion community evolves. Team leaders will have access to specific areas of the site that they are responsible for. And, blog submissions are welcomed from anyone working in the Commotion community. In fact, if you have something you’d like to write about, contact us! Thanks to everyone who has been involved in this design process! We look forward to a vibrant online community that helps newcomers try out and understand mesh networking. Please share your feedback about the new site by submitting a comment below.

Tags:

- drupal  + drupal  - branding  + branding  diff --git a/test.commotion/_site/blog/2012/10/08/diving-deeper-meshaging/index.html b/test.commotion/_site/blog/2012/10/08/diving-deeper-meshaging/index.html index f1ac4ab7..53d44cc9 100644 --- a/test.commotion/_site/blog/2012/10/08/diving-deeper-meshaging/index.html +++ b/test.commotion/_site/blog/2012/10/08/diving-deeper-meshaging/index.html @@ -699,13 +699,13 @@

2012-10-08 / The Work Department

In our recent blog post about messaging, we introduced our “meshaging” (basic chat) application and explained some of the plans for our future work with it. We are still working on this project and have diagrammed how exactly communication happens in the application. This has improved our internal process and we think it's beneficial to share. Compared to centralized, server-based systems, decentralized networking applications are a bit messy: with the benefit of decentralization comes the cost of increased complexity. Maintaining consistency of data across a mesh network is a hard problem to solve, and there are plenty of interesting approaches to address this problem. As designers, we became interested in embracing inconsistency: what systems could exist, or even thrive, in a network of inconsistent connections or transient devices? This is important to consider because a mesh network could be constantly changing. To explore the subject of decentralized communication, we decided to work through the design of a mesh network chat application in which nodes would serve as chat hubs. We considered what a decentralized chat application would look like with varying levels of message-sharing or replication between neighbor nodes. We used the analogy of a chat application because of its simplicity and its generality, but you can replace “chats” with any sort of one-to-many message. Actually, as an exercise, you really should try and think of other types of messages that might be transported over a mesh network! Imagine a network of thermometers in a greenhouse, or a network of motion sensors that trigger floodlights, or many other possibilities. Diagram 1 (above) illustrates a chat application in which nodes broadcast messages only to locally connected clients (zero hops). The numbers 1, 2, and 3 represent nodes connected to the mesh network, and the little people icons designated with letters represent the people connected to each of those nodes. In this scenario, users can chat with other users on the same node. For example, Person H can chat with Person J because they are both connected to Node 2. They cannot however chat with Person K or Person D, because those users, though connected to the mesh network, are on different nodes. Diagram 2(above) illustrates users on Node 1 communicating (zero-hop/no-broadcast chat system). Diagram 3 (above) illustrates a next-neighbor broadcast chat system, in which nodes would broadcast all messages to nodes within a one-hop distance. This system would allow a person to chat with people connected to their own node or their next neighbors, but not nodes two or more hops away. In Diagram 3, Person G can chat with Person C because they are both connected to Node 1. But in this stage Person G can also chat with Person J because J is connected to G’s next neighbor, Node 2. Person G could not chat with Person L though, because Node 3, which Person L is connected to, is two hops away. Diagram 4 (above) shows the next-neighbor broadcast chat system, illustrating users on Node 1 communicating with each other and users on Node 2. We hope that these diagrams can help spur conversations about decentralized application development. Stay tuned for more meshages.

Tags:

- messaging  + messaging  - chat  + chat  - ux  + ux  - applications  + applications  diff --git a/test.commotion/_site/blog/2012/10/08/step-step-creating-and-installing-package-commotion/index.html b/test.commotion/_site/blog/2012/10/08/step-step-creating-and-installing-package-commotion/index.html index e75f6751..eb7ebb8e 100644 --- a/test.commotion/_site/blog/2012/10/08/step-step-creating-and-installing-package-commotion/index.html +++ b/test.commotion/_site/blog/2012/10/08/step-step-creating-and-installing-package-commotion/index.html @@ -731,13 +731,13 @@

Get a taste of Commotion

Here's a virtual pat on the back. Now you’ll be ready to install example applications and test them for yourself. In our next post, we’ll show you how to install and use the chat application we developed.

Tags:

- chat  + chat  - applications  + applications  - routers  + routers  - messaging  + messaging  diff --git a/test.commotion/_site/blog/2012/11/01/updating-commotion-package/index.html b/test.commotion/_site/blog/2012/11/01/updating-commotion-package/index.html index b8a3b524..79692c2a 100644 --- a/test.commotion/_site/blog/2012/11/01/updating-commotion-package/index.html +++ b/test.commotion/_site/blog/2012/11/01/updating-commotion-package/index.html @@ -736,13 +736,13 @@

The Fun Part

Then, follow the same workflow described above for the ws-routing package to install commotion-chat on your router. After installing these packages, you may need to reboot the router. Hover over "System," and click "Reboot." Confirm, wait a few minutes, and then try visiting your router's splash page. If you installed/updated commotion-ws-routing and commotion-chat successfully, you can now click on the "Chat" menu item under "Applications" and try out the chat app!

Tags:

- chat  + chat  - applications  + applications  - routers  + routers  - messaging  + messaging  diff --git a/test.commotion/_site/blog/2012/11/06/brainstorming-how-neighborhood-power-grids-could-work-community-mesh-networks/index.html b/test.commotion/_site/blog/2012/11/06/brainstorming-how-neighborhood-power-grids-could-work-community-mesh-networks/index.html index a2f8bd7d..bff1544e 100644 --- a/test.commotion/_site/blog/2012/11/06/brainstorming-how-neighborhood-power-grids-could-work-community-mesh-networks/index.html +++ b/test.commotion/_site/blog/2012/11/06/brainstorming-how-neighborhood-power-grids-could-work-community-mesh-networks/index.html @@ -699,11 +699,11 @@

2012-11-06 / The Work Department

A community wireless network can provide a reliable conduit for many types of communication. We might initially think of this communication within a human context — sharing music with your friend across town, spreading news to your city about an upcoming event, responding to an emergency, or asking questions of a local politician on a discussion forum. But, in a world that runs parallel to the Internet we use everyday, our communication networks are used by all sorts of machines to make our society an exponentially more productive and automated place. These “robots” in our communities, all of those appliances and devices with embedded computers, could also benefit from a community mesh network. Moving into the future, we’ll be inspired to redesign some of these helpful robots and algorithms to be more decentralized and useful on hyperlocal levels. In Detroit, we’re thinking more about what role a community wireless network could play in organizing automated communication to better sustain our human neighborhoods and communities. For example, a house produces a never-ending stream of usage data ranging from kilowatt-hours of electricity to gallons of water to cubic-feet of gas. Hobbyists have taken an interest in this data, especially electrical usage. The current trend of home energy information technology is inspirational yet clearly missing some components that would increase democratic control. Energy companies have certainly accumulated a wealth of innovative and efficient systems for large-scale electricity distribution, but what if we came up with simple systems that enable neighbors to easily share power grid information over a community wireless network? Here, we enter the realm of local energy sharing and distribution built on locally owned and controlled data systems. Beyond the benefits of each home knowing its impact on the energy use of the community, this distributed monitoring could be useful to people who use alternative energy sources like wind or solar power. These energy systems require a charge controller and other electronics which often have data sharing systems or APIs similar to usage monitors. This software could use community wireless networks to manage energy sharing. For example, a house with solar panels could share energy with its neighbor with wind turbines on sunny days, and the neighbor with wind turbines could share energy with the solar house on windy days. On days that are both windy and sunny, both houses could contribute to a shared pool of batteries or donate the excess power to local community services at no cost to themselves. Household energy usage data could be aggregated within applications like Tidepools so community members could compare location-specific energy consumption. And, because of the self-healing nature of mesh networks, these energy-sharing systems could be more resilient during times of disaster or failing infrastructure. In Detroit, the team at The Work Department has also been brainstorming with two community projects: Power House Productions and Mt. Elliott Makerspace. Whether through youth workshops or architectural installations, these groups work to introduce people to alternative energy and neighborhood-level systems — concepts that can be related to community wireless networks. We're also keeping tabs on an exciting project called the “Solar Pocket Factory” because small-scale solar technology could play a crucial role in letting a delay-tolerant mesh network scale. As our conversations progress, we’ll post more notes on this blog.

Tags:

- community wireless  + community wireless  - energy  + energy  - detroit  + detroit  diff --git a/test.commotion/_site/blog/2012/11/14/cost-mesh-networks/index.html b/test.commotion/_site/blog/2012/11/14/cost-mesh-networks/index.html index ff2feae1..c4ab89e6 100644 --- a/test.commotion/_site/blog/2012/11/14/cost-mesh-networks/index.html +++ b/test.commotion/_site/blog/2012/11/14/cost-mesh-networks/index.html @@ -699,13 +699,13 @@

2012-11-14 / s2e

Tags:

- mesh  + mesh  - cost  + cost  - price  + price  - hardware  + hardware  diff --git a/test.commotion/_site/blog/2013/02/02/case-study-red-hook-initiative-wifi-tidepools/index.html b/test.commotion/_site/blog/2013/02/02/case-study-red-hook-initiative-wifi-tidepools/index.html index 69d2874c..c4ecc45d 100644 --- a/test.commotion/_site/blog/2013/02/02/case-study-red-hook-initiative-wifi-tidepools/index.html +++ b/test.commotion/_site/blog/2013/02/02/case-study-red-hook-initiative-wifi-tidepools/index.html @@ -699,19 +699,19 @@

2013-02-02 / georgia

Tags:

- red hook  + red hook  - hardware  + hardware  - cost  + cost  - community wireless  + community wireless  - applications  + applications  - research  + research  - mesh  + mesh  diff --git a/test.commotion/_site/blog/2013/02/25/troubleshooting-wireless-network-technical-physical-and-social-needs/index.html b/test.commotion/_site/blog/2013/02/25/troubleshooting-wireless-network-technical-physical-and-social-needs/index.html index 69104378..569c8fd5 100644 --- a/test.commotion/_site/blog/2013/02/25/troubleshooting-wireless-network-technical-physical-and-social-needs/index.html +++ b/test.commotion/_site/blog/2013/02/25/troubleshooting-wireless-network-technical-physical-and-social-needs/index.html @@ -699,19 +699,19 @@

2013-02-25 / georgia

Tags:

- red hook  + red hook  - hardware  + hardware  - community wireless  + community wireless  - mesh  + mesh  - troubleshooting  + troubleshooting  - site visits  + site visits  - maintenance  + maintenance  diff --git a/test.commotion/_site/blog/2013/02/25/warning-label-development-part-1/index.html b/test.commotion/_site/blog/2013/02/25/warning-label-development-part-1/index.html index 498d8961..2febc740 100644 --- a/test.commotion/_site/blog/2013/02/25/warning-label-development-part-1/index.html +++ b/test.commotion/_site/blog/2013/02/25/warning-label-development-part-1/index.html @@ -725,17 +725,17 @@

2013-02-25 / OTI

In Part 2, we'll go over how we used this list of unimplemented security features to develop a warning label.

Tags:

- warning  + warning  - label  + label  - security  + security  - anonymity  + anonymity  - privacy  + privacy  - research  + research  diff --git a/test.commotion/_site/blog/2013/02/25/warning-label-development-part-2/index.html b/test.commotion/_site/blog/2013/02/25/warning-label-development-part-2/index.html index f644c66e..d732e6f8 100644 --- a/test.commotion/_site/blog/2013/02/25/warning-label-development-part-2/index.html +++ b/test.commotion/_site/blog/2013/02/25/warning-label-development-part-2/index.html @@ -706,17 +706,17 @@

2013-02-25 / OTI

  1. Refrences
  2. https://www.osha.gov/dsg/hazcom/hc2inf2.html#3.2.1
  3. http://www.diriwa.org/
  4. https://www.torproject.org/
  5. http://killerapps.foreignpolicy.com/posts/2012/11/05/internet_in_a_suitcase_ready_for_field_testing
  6. https://www.nytimes.com/2011/06/12/world/12internet.html?pagewanted=all&_r=1&
  7. http://www.wired.com/threatlevel/2011/12/internet-suitcase-dc/all/
  8. https://commotionwireless.net/
  9. http://www.usability.gov/articles/newsletter/pubs/032010news.html
  10. https://www.osha.gov/dsg/hazcom/hc2inf2.html#3.3.2
  11. https://www.osha.gov/dsg/hazcom/hc2inf2.html#3.1.8.1
  12. http://www.ismp.org/newsletters/acutecare/articles/20060824.asp
  13. https://www.osha.gov/dsg/hazcom/hc2inf2.html#3.1.6.8

Tags:

- warning  + warning  - label  + label  - security  + security  - anonymity  + anonymity  - privacy  + privacy  - research  + research  diff --git a/test.commotion/_site/blog/2013/03/28/open-technology-institute-endorses-battle-mesh-v6/index.html b/test.commotion/_site/blog/2013/03/28/open-technology-institute-endorses-battle-mesh-v6/index.html index 8f94abc7..8ab81563 100644 --- a/test.commotion/_site/blog/2013/03/28/open-technology-institute-endorses-battle-mesh-v6/index.html +++ b/test.commotion/_site/blog/2013/03/28/open-technology-institute-endorses-battle-mesh-v6/index.html @@ -699,13 +699,13 @@

2013-03-28 / s2e

Since 2009, wireless mesh enthusiasts and community networking activists from across the globe have come together for a tournament of a social nature: "Wireless Battle of the Mesh". Each battle is held in a different European location, creating a unique series of testbeds for this band of hacktivists and wireless innovators to examine the performance of the various mesh data routing protocols. Wireless mesh projects are judged on many features including network capacity, recovery, and node-discovery. The creators and implementers of protocols such as Babel, B.A.T.M.A.N., BMX, OLSR, and 802.11s come together each year to compete and swap notes and code. This year’s events will be held at the University of Aalborg, Denmark, from Monday, April 15th through Sunday, April 21st. The Open Technology Institute (OTI) sees Battlemesh as a great knowledge sharing event that has, and continues to be, critically important to groundbreaking innovation in the field of wireless mesh networking. Events like these help foster the development of grassroots community networks around the globe. OTI endorses and supports the Battle of the Mesh v6 for its crucial role in advancing the state of the art. OTI will be sending a team of technologists to the Battle of the Mesh to participate in the event’s talks and to help with network setup. OTI will also donate hardware to help extend the pool of available network devices. To see the list of the endorsers or learn more about the project, please visit the main Battlemesh website.

Tags:

- battlemesh  + battlemesh  - mesh  + mesh  - olsr  + olsr  - testing  + testing  diff --git a/test.commotion/_site/blog/2013/06/05/building-community-controlled-digital-infrastructure-detroit/index.html b/test.commotion/_site/blog/2013/06/05/building-community-controlled-digital-infrastructure-detroit/index.html index 70ff6c32..6d49101c 100644 --- a/test.commotion/_site/blog/2013/06/05/building-community-controlled-digital-infrastructure-detroit/index.html +++ b/test.commotion/_site/blog/2013/06/05/building-community-controlled-digital-infrastructure-detroit/index.html @@ -699,17 +699,17 @@

2013-06-05 / georgia

Tags:

- detroit  + detroit  - community wireless  + community wireless  - digital stewards  + digital stewards  - mesh  + mesh  - amp  + amp  - amc  + amc  diff --git a/test.commotion/_site/blog/2013/06/05/commotion-dr1-stable-release-notes-dr11/index.html b/test.commotion/_site/blog/2013/06/05/commotion-dr1-stable-release-notes-dr11/index.html index 55a9fc98..1d6f7124 100644 --- a/test.commotion/_site/blog/2013/06/05/commotion-dr1-stable-release-notes-dr11/index.html +++ b/test.commotion/_site/blog/2013/06/05/commotion-dr1-stable-release-notes-dr11/index.html @@ -731,7 +731,7 @@

Included Components

Tags:

- release  + release  diff --git a/test.commotion/_site/blog/2013/06/05/serval-mesh-extender-field-trial-national-mall/index.html b/test.commotion/_site/blog/2013/06/05/serval-mesh-extender-field-trial-national-mall/index.html index 37fcb0d9..82f6d44f 100644 --- a/test.commotion/_site/blog/2013/06/05/serval-mesh-extender-field-trial-national-mall/index.html +++ b/test.commotion/_site/blog/2013/06/05/serval-mesh-extender-field-trial-national-mall/index.html @@ -699,15 +699,15 @@

2013-06-05 / OTI

On an uncharacteristically chilly May morning, members of the Commotion and Serval projects set out for the National Mall in Washington, DC to test Serval's latest piece of hardware: the Mesh Extender. Commotion Wireless is an open-source toolkit of software, documentation, and training materials that strengthens communities by allowing them to build their own local communication infrastructure. Serval is a mesh networking software designed to act as an ad hoc communications network where other infrastructure is either absent or unavailable – such as in remote areas or disaster scenarios. Some of us stood at the Washington Monument while others were at the Lincoln Memorial – a distance of nearly a mile. Using two Mesh Extenders, we successfully sent text messages and shared files between our phones (running Serval) – entirely independent of the cellular infrastructure. On the way back to the office, we hopped on the Metro – DC's subway system – to run another impromptu field test. From opposite ends of the train, we were able to send and receive messages through six subway cars (and their passengers) while the train was moving. That meant we could do something Metro riders usually can't – send and receive messages while in the subway tunnels. These results represent a significant breakthrough, as until now Serval and Commotion have been limited by the relatively short range and low power of Wi-Fi. In addition to increasing range and power, the Mesh Extender removes a major obstacle to widespread adoption of mesh for mobile phones – rooting. Normally a prerequisite for Androids to connect to a mesh network, this technically challenging process for installing a new operating system can cause problems down the road for the rooted phone. In this case, the Mesh Extender routes the messages, not the users' phones, eliminating the need for rooting. However, the Mesh Extender is still a prototype. Software issues make voice calls possible but indecipherable. Further development, including better error correction and noise cancellation, will allow for not only voice calls but potentially even longer-distance connections. Despite these remaining challenges, the Mesh Extender is a huge step towards reliable decentralized infrastructure. A device with multiple radios and a small processor, the Mesh Extender essentially acts as a relay between phones running Serval software. It is lightweight, portable, and relatively cheap and easy to build. The parts can be purchased and assembled for as little as $99. Impressively, the battery can support three to five days of continuous use. The Mesh Extender uses omni-directional antennas (as opposed to point-to-point links), which make for much easier set up and configuration, and allow for truly mobile networks. The Mesh Extender operates simultaneously on the 2.4 GHz and 900 MHz bands, both of which are unlicensed. This allows phones running Serval to tether to the closest Mesh Extender over Wi-Fi (2.4 GHz), while the Mesh Extenders themselves communicate over the 900 MHz band, which is both less congested and has better propagation characteristics.

Tags:

- messaging  + messaging  - applications  + applications  - chat  + chat  - site visits  + site visits  - serval  + serval  diff --git a/test.commotion/_site/blog/2013/07/01/commotion-travels-india-first-international-workshop/index.html b/test.commotion/_site/blog/2013/07/01/commotion-travels-india-first-international-workshop/index.html index ff8ff312..11410750 100644 --- a/test.commotion/_site/blog/2013/07/01/commotion-travels-india-first-international-workshop/index.html +++ b/test.commotion/_site/blog/2013/07/01/commotion-travels-india-first-international-workshop/index.html @@ -721,19 +721,19 @@

2013-07-01 / gerety

To this last point, one participant threw his phone to the ground, picked it up and put it back together - all to highlight the need for people to be able to break and fix the technology they rely on. This theme continued throughout the workshop when the network needed troubleshooting or equipment did not work as expected. The process of troubleshooting and experimentation was an important component of the learning, and led to the discovery of a few bugs in the newest DR1.1 release. Even more valuable was the feedback from participants, which will continue to inform the direction of the Commotion project. The ideas and lessons coming out of the workshop are already being applied in the office to the Commotion code, to the training tools we use in our work, and in the networks we partner with in Detroit and Brooklyn. At the end of the week-long workshop the network was working well, and demonstrated the properties of a dynamic mesh by allowing us to connect a portable node as we moved through a grassy field, down the dirt path to a rooftop restaurant to toast our successes and future collaborations.

Tags:

- mesh  + mesh  - site visits  + site visits  - gource  + gource  - git  + git  - visualization  + visualization  - troubleshooting  + troubleshooting  - recommendations  + recommendations  diff --git a/test.commotion/_site/blog/2013/07/11/commotion-development-progress-visualized/index.html b/test.commotion/_site/blog/2013/07/11/commotion-development-progress-visualized/index.html index fdc92768..4828e15c 100644 --- a/test.commotion/_site/blog/2013/07/11/commotion-development-progress-visualized/index.html +++ b/test.commotion/_site/blog/2013/07/11/commotion-development-progress-visualized/index.html @@ -701,9 +701,9 @@

2013-07-11 / s2e

Commotion Development Progress from OTI Web Team on Vimeo. We made some tweaks to gource to remove much of the clutter, including the more than a dozen developers buzzing around the various projects, to make it easier to focus on how our projects have grown in the past couple of years. We do think our developers deserve loads of credit for the hard work that they do (one of us wrote this post).

Tags:

- development  + development  - visualization  + visualization  diff --git a/test.commotion/_site/blog/2013/07/26/mountain-top-repeaters-and-solar-powered-wi-fi-guest-post-nepal-wireless/index.html b/test.commotion/_site/blog/2013/07/26/mountain-top-repeaters-and-solar-powered-wi-fi-guest-post-nepal-wireless/index.html index fbc62f1d..89266653 100644 --- a/test.commotion/_site/blog/2013/07/26/mountain-top-repeaters-and-solar-powered-wi-fi-guest-post-nepal-wireless/index.html +++ b/test.commotion/_site/blog/2013/07/26/mountain-top-repeaters-and-solar-powered-wi-fi-guest-post-nepal-wireless/index.html @@ -705,9 +705,9 @@

2013-07-26 /

Nepal Wireless Networking Project was started in the Nangi village of Nepal. Nangi is an isolated village with about 800 residents. People of the village are subsistence farmers and they use primitive farming tools such as wooden plows, iron spades, axes, and sickles etc. Villagers carry all kinds of loads such as supplies, firewood, building materials, composts and others on their back, which they have been doing for centuries. Before 2001, no villager had any idea as what an Internet was or what a computer looked like. There was no telephone or electricity in the villages. The villagers had to walk five to eight hours to the nearest city just to make outside telephone calls. In the absence of modern communication and transportation means, villagers had to use human messengers to send messages from one village to another. In 2001, when the plan was made to connect Nangi village to Pokhara city through Wi-Fi to bring the Internet, the responses from expert communication engineers were negative. Their main concern was with the simple Wi-Fi equipment that we proposed to use, which had transmit power of 60 mW and maximum outdoor range of 100 meters as specified in the manual. The total aerial distance between Nangi and Pokhara was 40 kilometers. Therefore, the communication engineers concluded that it was impossible to connect Nangi village to Pokhara with Wi-Fi. In spite of the negative feedback, the team members of Nepal Wireless decided to continue the experiment. The experiment was conducted for more than a year and was successful to the surprise of the technical experts, who had been skeptical of the project. As for the power needed at the repeater stations, solar panels and wind generators were used to charge the storage batteries. Thus Nepal Wireless Networking Project was born informally in 2002 by connecting a small village using simple Wi-Fi devices and home built antennas. Technically, we were running the network illegally because we had not gotten the licenses that the government of Nepal required at that time. It was almost impossible to import wireless equipment from abroad – we smuggled all the equipment from Singapore and the US. Moreover it was very risky to our lives to bring the equipment and build the network during that period of political conflict in Nepal. We might have been killed or tortured either by the government or insurgent forces if something had gone wrong. Luckily, we survived. In 2006, the political situation stabilized, followed by de-licensing key wireless bands. The team members of the project at the beginning had planned to connect only six villages of one district. However, the demand for the wireless network came from many villages. Therefore we expanded the network to many villages in a time span of over ten years and it is still growing. Now it has connected more than 160 villages of 15 districts of Nepal. The villages that are connected to the network get Internet and intranet services via servers in big cities like Kathmandu and Pokhara, where internet service providers are available. The servers in Kathmandu and Pokhara (200 kilometers apart) are linked through a leased optical fiber line. A series of mountaintop repeater stations relay the signal from the cities up into the mountain villages. Some of the relay stations are built at 4,000 meters or higher in the mountains. There are also access points at the mountaintop relay stations to distribute Internet to end users in the neighboring villages. Villages are connected to the access points using point-to-point or point-to-multipoint wireless. The high-speed backhaul radios at the relay stations operate on a dedicated core local area network (LAN) that reaches from the base stations (Pokhara and Kathmandu) to different areas through relay stations. The longest point-to-point link of the project is 59 kilometers from one mountaintop to another. The distance of the villages from the access points ranges from two kilometers to eighteen kilometers. The districts connected to the network are divided into different subnets in order to manage the network smoothly. Thus the villages in each of the network’s coverage areas from the relay stations operate on separate local LANs through VLAN switches. Routers at each of the relay stations provide DHCP services to the end users. Step by step, we introduced services through different applications such as e-learning, tele-medicine, tele-teaching, tele-training and e-commerce. Many villagers have built communication centers to learn and use the Internet. People are using the Internet for money transfer services because many young people from the villages go to work abroad and send money to their families on a regular basis. Additionally, Nepal Wireless is working with different research groups to monitor glacial lakes, weather, and climate change in the Himalayas. Nepal Wireless is doing some research and development work with different technical groups to develop applications that will be useful for rural people – such as building simple ECG machines for rural clinics, building poacher tracking system in a national park, and implementing systems for the safety of trekkers travelling on the mountain trails . However, the main goal of the project is to bridge the digital divide. Therefore the project is focused more on connecting as many rural schools as possible and providing computer training to the students, school teachers, and villagers. Every year we send university students from Nepal and abroad as volunteers to provide computer training to the people in rural areas. The second area of focus is to provide health services to the villagers of remote areas through tele-medicine. We found this to be urgent because there are no clinics and medical doctors in the remote villages. The project has connected ten rural clinics to a hospital in Kathmandu on the network. The rural health workers communicate with the medical doctors in the city hospital to help the patients in the villages. It runs computer training for the health workers and teaches them how to use computers to connect to the city hospital through video conferencing. Now the main focus of Nepal Wireless Networking Project is to help the villages located in remote Himalayan valleys get connected to the Internet, where no commercial service providers have reached. Nepal Wireless Networking Project has come a long way, but we are still learning how to provide maximum benefit of information technology to poor people living in rural areas.

Tags:

- guest post  + guest post  - community wireless  + community wireless  diff --git a/test.commotion/_site/blog/2013/07/26/video-community-technology-and-training/index.html b/test.commotion/_site/blog/2013/07/26/video-community-technology-and-training/index.html index 3087420a..7c501ea0 100644 --- a/test.commotion/_site/blog/2013/07/26/video-community-technology-and-training/index.html +++ b/test.commotion/_site/blog/2013/07/26/video-community-technology-and-training/index.html @@ -700,15 +700,15 @@

2013-07-26 / darbyhickey