> "[The [Global Innovation Gathering](https://globalinnovationgathering.org/) or] GIG is the global network of social and tech innovators. > > As an international network and NGO, > we aim to create meaningful connections between innovators and positively impact the policies and frameworks for grassroots innovation." > > -- From the [GIG's about page](https://globalinnovationgathering.org/about-us/)

!!! warning Early draft document with pending content and without external proofreading.

![ Figure [gig-wiki-preview]: [GIG portable wiki](https://mutabit.com/repos.fossil/gig/uv/wiki/) in its current state, as a stackable deck of info cards, called tiddlers. ](https://i.imgur.com/edeCYCi.png)

Overfill container

!!! tip [Visit the GIG portable wiki](https://mutabit.com/repos.fossil/gig/uv/wiki/).

!!! This data narrative prototypes how to republish and offer the GIG members information of [our web site](https://globalinnovationgathering.org/), made with [WordPress](https://wordpress.org/), as a portable and interactive document, contained in a single HTML, made with [TiddlyWiki](https://tiddlywiki.com/). The intentions are several: - Making GIG members information available in context with low/inttermittent internet connectivity, frequent in many places of the Global South. - Exploring possibilities to exhibit connections and activity in the network, beyond what is possible with WordPress (WordPress is an example of what is called a LAMP tech stack, for being constructed by using Linux, Apache, MySQL and PHP). - Deploying what the [IndieWeb](https://indieweb.org/) movement has called a [PESOS](https://indieweb.org/PESOS) (Publish Everywhere, Syndicate --on your-- Own Site) strategy for our web presenses, collecting our info from other places and interconnecting them back here -- the supplementary approach is called [POSSE](https://indieweb.org/POSSE)--. - Mapping grassroots innovation by using grassroots innovation. In particular, we are going to use several developments of the [Grafoscopio](https://mutabit.com/grafoscopio/en.html) community, (which is part of the GIG network): - Using **pocket infrastructures** as an alternative tech stack for our web presenses. [Pocket infrastructures](https://mutabit.com/repos.fossil/grafoscopedia/uv/#Pocket%20Infrastructures) are interconnected arrangements of curated tools/tech which are portable, simple, extensible, [local first](https://www.inkandswitch.com/local-first/) and can be deployed in variety of hardware. Because of that, they are less resource intensive, more expressive and more explicit about its deconstruction and recontextualization possibilites. - Using **interstitial programming**: a way of modifiying/extending sociotechnical systems by modifying/extending what happens between them, instead of approaching from inside. In this prototype, we are not modifying WordPress or even TiddlyWiki, but instead, manipulating and connecting the data and tools where such data moves and lives. - Using **malleable metatools**: tools that are used to define and extend tools and their workflows, including themselves. This allows us to adapt the tool to the problem and not the other way around. The prototype showed here displays such adaptation and customization of tools and their workflows to the unique problem at hand. - Showcasing portable and interactive documentation tech stacks that can be used for other GIG projects. The document you are reading now is part of such tech stack. - Incidentally, it's a practical use case on how to do web scrapping on public data using [Pharo](https://pharo.org/) / [Glamorous Toolkit](https://gtoolkit.com/). For more extended documentation on that subject, including the concepts applied but not explained in the scrapping code here, we advice to read the book: [Scraping HTML with XPath](https://books.pharo.org/booklet-Scraping/). Because its exploratory nature, this document goes in a pretty technical details in its current form. But, in the future, the usage of the interactive documentation stack, to update the portable wiki and its visualizations/connections or other tasks, will not require big technical expertise as _it is not required, even now, to use the resulting prototype in its current state_. The rationale, technologies, procedures and outputs behind this prototype are discussed in more detail below.

# Motivations and overview

One of the main values of GIG is its interconnected diversity, that is celebrated each year in a face to face meeting in the context of [Republica](https://re-publica.com/), in Berlin, where also our NGO (Ferhain) is legally constituted. Furthermore, we, the GIG members, have several meetings during the year, pre and post Republica, and we use a variety of digital tools and infrastructures to coordinate them and our actions.

This data narrative (combining code, prose and data) prototypes how our digital tools and infrastructures could account for our interconnected diversity, making explicit how such tools/infrastructures are plural, contextual and flexible. For that, this data narrative "wikifies" the members pages in our main web site and showcases an alternative take on it and how our public data can be interconnected in several ways and deployed in sites with low/inttermitent internet connectivity, which are pretty common in the Global South. This alternative "wikified digital habitat" not only deconstructs our main web site, but also explores, in the no so distant future, how can we take several public data sources to create more explicit views and connections inside and beyond the GIG network and communicate in another way the "beat" of this living community.

As members, we can access the GIG members public data by just asking for it. But this data scrapping technique is used also by some members in grassroots communities, particularly in the [Grafoscopio](https://mutabit.com/grafoscopio/en.html) community, as an exercise on civic tech and critical code/data literacy by taking/making new approaches on publicly available data (for example in NGO's or Government web sites), where data access/undersdating is usually lower. So, it is also a good opportunity to display such critical approaches.

Our main site is done done in WordPress. We are going to use [TiddlyWiki](https://tiddlywiki.com/) as a way to package and present the GIG network members public data in a simple, portable and interactive way. The idea is to "recreate" the GIG members page and to have details on each member inside TiddlyWiki, so we can provide such information in places with low/inttermitent connectivity, where WordPress is too heavy, complicated or resource intensive. As we told before, this can be also a way to package interactive hypertextual documentation, developed by GIG's members/projects, for such contexts and to showcase the activity and possible connections of GIG members beyond what is possible with WordPress.

The [members page](https://globalinnovationgathering.org/members-map/) of our site looks like this:

![ Figure [wp-members-page]: Snippet of the [Members web page at GIG](https://globalinnovationgathering.org/members-map/). ](https://i.imgur.com/VuLzlYt.png)

If we click on any member's avatar we get his/her particular page:

![ Figure [wp-member]: A GIG member's details page. ](https://i.imgur.com/qhHqpGx.png)

And the end of this data story, we'll end with a self contained [GIG portable wiki](https://mutabit.com/repos.fossil/gig/uv/wiki/), that looks like this:

![ Figure [portable-wiki]: [GIG portable wiki](https://mutabit.com/repos.fossil/gig/uv/wiki/) in its current state, as a stackable deck of info cards, called tiddlers. Each time the wiki page is releaded the members are rearranged and a new member is selected randomly as you can see comparing this with figure [gig-wiki-preview]. ](https://i.imgur.com/l7p9CBD.png)

Overfill container

!!! tip Notice that you can use/browse our current GIG portable wiki prototype without any technical expertise on the following data narrative. Just browse [GIG portable wiki](https://mutabit.com/repos.fossil/gig/uv/wiki/).

This data narrative showcases also a way of "enactive discourse", that is common in hacker/maker spaces, and is embodied in actions and tools instead of (only/mainly) words. Also makes the de/re-construction replicable and recontextualizable.

!!! This prototype is done on a voluntary basis, after the inspiration and engagement of meeting the GIG members in Berlin on 2023. So, it has this particular relaxed rhythm of serendipity and exploration without deadlines or particular agendas.

# Prerrequisites

To download and "reproduce" this note from the web you will need to have preinstalled the following software and be familiar with its usage: * [Markdown](https://en.wikipedia.org/wiki/Markdown) and/or [Markdeep](https://casual-effects.com/markdeep/): are the ligth formats for the prose part of this data story. * [Pharo](https://pharo.org/) is the programming environment and language for the code part of this data story. * ※ [Glamorous Toolkit](https://gtoolkit.com/) , also know as GToolkit or GT: provides the live coding and interactive documentation environment to write, modify and execute this document. * [MiniDocs](https://code.tupale.co/Offray/MiniDocs): contains utilities to work with Markdeep and other markup languages and tools in our publishing workflow and to produce the web version of this very document that you maybe reading online (you may be reading this inside Glamorous Toolkit). * [TiddlyWikiPharo](https://code.tupale.co/Offray/TiddlyWikiPharo/): utilities to work TiddlyWiki inside Pharo. *  ※ [TiddlyWiki](https://tiddlywiki.com/): The portable and extesible wiki engine, self contained in a single HTML file. * [Fossil](https://fossil-scm.org/) (optional): Is the Distributed Control Version System (DCVS) to publish this data story, the resulting prototype, the processed data and the history of all that.

!!! tip If you are unfamiliar with these tools, don't worry if the previous lists seems extensive. As usual with pocket infrastructures, one already includes support for the others or it is able to install/bootstrap them. We have marked such tools with a reference mark ※. As you can see, our requirements are reduced to a couple, and the extra links detail how to extend our already installed tools into a complete customized workbech for the tasks at hand.

# Collecting members data from our
WordPress site

Let's see the source code of the members page as a document tree, to locate relevant member's data.


We want to locate which part of this document tree contains the branches with the members information. So, we use the web browser's inspector to look for such elements in the document tree

![ Figure [inspecting-members-page]: Using the web browser's inpector to locate members information in the web page. ](https://i.imgur.com/UkltYDN.png)

As we can see, from the figure [inspecting-members-page], the HTML class `list-wrap` inside the document, is the one containing the information of each member. So, we are going to collect all that information in our document.

![ Figure [wp-memberlist-code]: Exploring all the members information in a programmatic way ](https://i.imgur.com/zml7Cf1.png)

As shown in the red boxes of the figure [wp-memberlist-code], we have the information of 100 members in the web page. And we can dig deeper to get more details on each one. Let's create a temporal collection with the details of the members:


Now that we have the collection of the overall members information, let's explore the details on a single members page, for example, the first in the collection. Again, we use the web browser's inspector to get an overview of the HTML markup where the data is hold:


And then, we can collect the information table rows, marked with the red boxes in the previous screenshot, for a particular member:


As we can see, in the red boxes of the image above, each response contains the name of the label and the name of the data value for such label. Lets's add both, label and value, to the information we are recolecting on each member and test it with the first members page:


Now we can collect and repeat the procedure for all the remaining members:

![ Figure [members-collection]: Partial view of the GIG members data as a Pharo collection. ](https://i.imgur.com/uylKk2B.png)

Which gives us the extracted collection with all the data we need. To access it in a more easy way, we can store it as a plain text file.

Which ouputs a a single plain text file, located in our computers' temporal directory, which looks like this:

 plain text file. ](https://i.imgur.com/g9NwpEr.png)

It is important to publish the previous file is uploaded to a public web location, so we can use its web address for the next sections. Publishing can be done in different ways, using closed services/tech or open ones like [Internet Archive](https://archive.org/), Git of [Fossil](https://fossil-scm.org/)., In our case, using Fossil, the [members data online file](../../../../file?name=wiki/members-wp.ston&ci=5537eaa5886efa26) looks like this:


By the end of this section, we have collected the public data of GIG members and it is now nicely collected and [published online](../../../../file?name=wiki/members-wp.ston&ci=trunk) . In the next section we're going to repackage such information as a TiddlyWiki interactive and self contained file.

# Understanding and standarizing members data

As we saw in the figure [members-collection], the amount of data each member has filled out is different, depending on which makes sense for each one/context. We would like to collect all the _kinds_ of data that the members have, so, we have better sense of the common data and the different one and also normalize the data we are going to enter using the conventions for TiddlyWiki. Let's collect all the kinds of data:


We may like to see an example of how a different data field is filled out, to get a better idea of it. Let's define a variable for collecting such field filling out examples

And let's collect some examples of how data fields have being filled out:

![ Figure [open-source-adoption]: Example of the filling of field value for 'Open source adoption'. ](https://i.imgur.com/MS3AD3j.png)

And let's zoom in other examples:

 


  _Comparing the data fields 'About the project' with 'About it'_

 

As we can see from the previous data exploration, some fields like `Autobiography Name` has been filled out with a kind of more open interpretation that may not offer consistent data for the members; while others collected in the data scrapping have redundancies (`name` with `Name`); and others have supplementary information in two places, like `About it` and `About the project`; and others have no information like the `Yet another photo`.

Let's do some extra data cleaning, to erase the afore mentioned redundancies and empty values:

With this deeper glimpse on members data, we are ready to adapt it to TiddlyWiki's conventions. Let's see the data fields and redefine them in a dictionary to represent the previous mentioned conventions:

And on the result, we use GT objects playground to do the manual fields renaming:


Let's test the keys replacement with the first member:

At now that we have tested with the first element, let's rename all members data fields:

![ Figure [curated-data]: Curated data of GIG members. ](https://i.imgur.com/uX51GGb.png)

A small, but important, detail is to verify that web links for the member and project pages, when present, are effectively a well formed link, starting with `http`.

Let's store this modified data in a temporal location

Now lets put in the web file we published in the Fossil repository. While this is not mandatory, it is a recommended practice to put the data under distributed version control systems (or DVCS), to see the changes on it, as we can see in the figure [data-diff] (data versioning is beyond the reach of this document, but I hope that the screenshot serves as a teaser to increase reader's curiosity).

![ Figure [data-diff]: Fossil showing the differences on how the data is changed as we understand it better. ](https://i.imgur.com/yXWswih.png)

With this deeper understand of the data provided by the GIG members and its curation and reorganization, we are ready to put such data into TiddlyWiki in our next section.

# Using TiddlyWiki to publish and
visualize members data

We are going to use the included and extened capabilities of TiddlyWiki, first to create the individual's members pages and then to query them and add templates a world map and some visualization capabilities.

## Selecting and customizing an initial wiki seed

Let's start selecting a premade TiddlyWiki template, or wiki seed (shown below), as they're called in the Grafoscopio community, that we'll personalize progresively, as we put data, show it and create visualizations.

Let's list all possible curated staring wiki seeds:


The previous seeds serve several purposes and all of them are a combination of functionality, content and look and feel. Some of them are full of content, that learners in the Grafoscopio community persolize as they learn, others are just bare templates that we can customize further without legacy content. We can browse each of those seeds with `TWSeed preview: 'seedName'` (where `seedName` can take any of the names shown in the reponse above. After exploring some, we are going to `Krystal Whitespace`, that is the wiki seed shown in figure [wiki-seed]

![ Figure [wiki-seed]: [Krystal Whitespace](https://krytsal-whitespace.tiddlyhost.com/#) starting wiki seed, that we are going to customize to contain GIG members data. ](https://i.imgur.com/cijOzZc.png)

Let's download Krystal Whitespace wiki seed in a custom directory:

!!! tip The folder `FileLocator documents / 'Otros/GIG/gig-repo'` in the previous code should be changed accordinly to the folder in our computer, where we want to store our wiki. In this example, it has been put in the same folder where our Fossil repository is located, in the `wiki/` subfolder.

Let's open the downloaded wiki in the web to start initial customizations:

!!! tip For saving wiki customizations, our web browser should have insalled a TiddlyWiki saving plugin. The one we advice is [Timimi](https://ibnishak.github.io/Timimi/)


In the next section, we will add members data to this wiki.

## Creating members' pages

As in previous sections, let's take a single data point of a member to transform it and once we understand such transformations, let's apply them to all the members data collection.

Let's select the example data point from the `membersCuratedData` we created in previous section. To showcase the advanges of publishing our data online, we are going to reload the `membersCuratedData` from the file published in the web, with this code.

!!! tip Notice that `fileLink`, in the code below, should be changed for the download link of the data in the place where is located):

With this reloaded data we are ready to start further customizations on the wiki seed.

We are going to transform the curated information of the first member into a unit of information of TiddlyWiki, called Tiddlers:


Let's export the `memberTiddler` as a JSON file in a temporal directory

and from the file navator, let's drag and drop with to a web browser window where we opened the wiki seed we are going to personalize.


An once the importation has ended, we can see the member with all the data fields we collected/curated from WordPress:


Now, let's create a Tiddler template from that initial data, that can be applied to all members. For that, we use a particular member with already filled data and enable the side by side preview in TiddlyWiki, to see the changes that the TiddlyWiki markup is producing in the member preview:

![ Figure [members-templating]: Side by side view of a members template source code (left) and its preview (right). ](https://i.imgur.com/FQTFe20.png)

Once we have the look we would like, we clone the resulting tiddler to a new one, rename it as `MembersTemplate` and erase the particular values of the fields. Because different members have filled out different data fields, we can use the operators and [filters language in TiddlyWiki](https://groktiddlywiki.com/read/#Filters), to put only the data they have filled out.

The new tiddler template would look like:

![ Figure [members-template]: Tiddler template with conditionals to show the information that members have filled out. ](https://i.imgur.com/2e6AZae.png)

And the complete source code of the members template, seen in figure [members-template], is this: ~~~

And, because of the [template reusage posibilities of TiddlyWiki](https://groktiddlywiki.com/read/#Templates%20and%20the%20Current%20Tiddler), we can reuse this template by just adding `{{||MemberTemplate}}` to the text of each member:

![ Figure [template-applying]: Side by side view of a template tiddler (left) and its application (right). ](https://i.imgur.com/Be9HYbm.png)

We are ready to apply such template to all the GIG members data, to finalize our importation of data from WordPress.

![ Figure [member-tiddlers]: GIG members as TiddlyWiki tiddlers inside Glamorous Toolkit. ](https://i.imgur.com/cC8pJll.png)

Then let's export all of them to a temporal folder

Once we have ended the members tiddlers exportation, whe should see a notification in the upper left corner of GT like this one:

![ Figure [exportation-notification]: Notification of the amoung of files exported from GT to the file system, corresponding the the amount of members we scrapped the initial information. ](https://i.imgur.com/g5sM8rc.png)

and drag and drop them to the local wiki:

![ Figure [tiddlers-drag-drop]: Drag and dropping all member tiddlers to be imported in the wiki. ](https://i.imgur.com/hAz8eBX.png)

To finalize, we create a tiddler, using TiddlyWiki's filters and templated to recollect and link all members information. If a particular member is clicked, his/her info card is deployed in detail:

![ Figure [members-tiddler]: Displaying the thumbnail information of all members and details when one is clicked. ](https://i.imgur.com/gcoVXGK.png)

Now that we have collected and displayed the members information, next subsections will take care of extending the information with some data visualizations.

## Members Worldmap

This section will show how to build a world map of GIG members and/or initiatives/organizations.

Let's start by collecting all different locations where GIG members and organizations / inititives are located around the world:

![ Figure [locations]: locations of GIG members and initiatives. ](https://i.imgur.com/OBx9PNX.png)

GIG members and projects are located in 147 territories (discounting `nil`), with several reaches: geographical (cities, countries, virtual, analogue) and linguistic (English, Spanish, Arab, Tagalog, among others). We should have different and supplementary maps to express the particularities of different geographical reaches: cities/towns, national/regional and global. Let's start with the first one

!!! warning To be finished...

## Network wordclouds

Here we'll build a word cloud of the members initiatives/organizations, as an example of visualizing posibilities the words that self-define us. Clicking on a word could show all the initiatives related with it.

!!! warning To be done...

## Microblogging activity stream

Here we'll recollecting all the members that have a ~~Twitter~~ [Mastodon](https://joinmastodon.org/) account and extend the [Socialmetrica](https://code.tupale.co/Offray/Socialmetrica/) package to showcase part of such activity, as Socialmetrica was doing previously with Twitter. Because Twitter limited the amount of tweets to be loaded and the scrapping posibilities, other open source microblogging places should have priority. It's is important to advice GIG members to take out Twitter data and migrate, as soon as possible, to Open Source Social Media, including microblogging.

!!! warning Socialmetrica needs to be extended to support Mastodon API.

!!! warning To be done...

## Generalizing activity streams

Here we would be addressing how to extend the previous example to other social media sites, even the ones powered by peer to peer protocolos (e.g. [Secure Scuttlebutt](https://scuttlebutt.nz/)), relay protocols ([NOSTR](https://usenostr.org/)) profesional sites (e.g. LinkdIn) developer repositories (e.g. Fossil, Git). This development, as the previous one, could involve funding and/or take longer time (particularly, if this is done only on a voluntary basis).

!!! warning To be done...

# Future work

Here we would talk about UI/theming and futher data collection, updating and interconnection and how this mapping could help to bootstrap a Small Indie Web of grassroots innovation/innovators where our data is originally published in our own infrastructure and shared elsewhere (the [POSSE](https://indieweb.org/POSSE) approach), increasing autonomy and facilitating capabilities building and sharing inside the GIG network. The role of chatbots and other agents going and connecting data source streams should be drafted.

On data collection, open source alternatives to Airtable, like [baserow](https://baserow.io/) ([baserow repository](https://gitlab.com/baserow/baserow)), [NocoDB](https://www.nocodb.com/) ([NocoDB repository](https://github.com/nocodb/nocodb)) or [PocketBase](https://pocketbase.io/) should be explored for more specific data collection (e.g. localizing the geographical and linguistic reach of the grassroots initiative). NocoDB and PocketBase have a SQLite backend available, which fits better our minimalist approach but they don't have a hosted free plan, which difficult exploration. baserow uses Postgres, but has a free hosted service. This things should be considered in this part of the prototype.

!!! warning To be done...

# Review and conclusions

In this data story we migrated from WordPress to TiddlyWiki to transform, interconnect and extend part of our web presenses and we used this interactive documentation to explain the process, its motivation and replicate its execution, so it can be extended/adapted in other contexts.

Let's compare the WordPress approach to the pocket infrastructures (pocket-i) approach we used here: | Criteria | WordPress | Pocket Infrastructures
(e.g. TiddlyWiki, GT) | |--|--|--| | **Working deliverable size** | 100Mb of minimal average[^wp-size] to couple of Gigabytes average | ~5 Mb | | **Architecture** | Monolithic | Modular | | **Complexity** | High | Low | | **Composabilily** | Low | High | | **Data storage** | MySQL or MariaDB database | Plain structured text files (JSON, STON, Markdown, Markdeep) | | **Data redundancy** | Difficult: database synchronization | Easy, via any DCVS[^dcvs], like Git or Fossil | | **Data querying/extension** | Yes, via WordPress API[^wp-api] | Yes, via plain files manipulation. | | **Data recollection and forms** | Only online. Integrated | Offline: integrated. Online: outsourced to third part services. | | **Extensibility** | Via plugins, themes and scripts. | Via plugins, themes and data narratives. | | **Theming versatility** | High | Low | | **Theming difficulty** | High | Low | | **SQL injections attacks** | Possible | Imposible | | **Knowledge about deployment and development** | Spread | Scarce | [^wp-size]: The average size in WordPress depend on many factors, as [detailed here](https://www.quora.com/How-much-storage-does-the-average-WordPress-website-use). But the site never be smaller than the installer + database + plugins + themes, which give us the minimal average size of 100 Mb aprox. [^wp-api]: See https://developer.wordpress.org/rest-api/key-concepts/ [^dcvs]: DCVS: [Distributed Control Version Systems](https://en.wikipedia.org/wiki/Distributed_version_control).

As we can see, the pocket infrastructures approach give us several advantages over the more hegemonic WordPress approach (42.8% of the top 10 million websites in 2021 used WordPress, [according to Wikipedia](https://en.wikipedia.org/wiki/WordPress)). One that, despite having its own peculiarites[^tw-critique], it's particularly well suited for the communities gathered around GIG and beyond. But, as happen with grassroots innovation, the advantages and knowledge about such approaches are peripherical and not well known/understood outside specialized communities. [^tw-critique]: TiddlyWiki faces also [its own problems](https://ibnishak.github.io/digital-garden/?stackedPages=%2FTiddlywiki%20-%20An%20exit%20interview&stackedPages=%2FTiddlywiki%20-%20Issues%20with%20NodeJS%20flavor) with large wikis that can be solved by increasing the infrastructure behind with NodeJS. In our [own experience](https://talk.tiddlywiki.org/t/tiddlywiki-as-a-note-taking-tool-positive-and-negative-aspects-lets-discuss/7497/16?u=offray), that limit is difficult to reach when wikis are split by topic/audience, as happens in many grassroots community settings.

This also makes it even more important to have mappings that allow us not only to understand where and how grassroots innovation occurs, but also to offer simpler, more autonomous and connected web sites for the memory of such globally spread but also localized enterprise.

!!! Also, GIG open data accounts for a living _ad-hoc_ cartography about grassroot innovation around the world. In this document we have given a preview of such richness, using an innovative approach emerged in one of the communities congregated by GIG, to prototype how our infrastructures and tools could improve in serving the purpose we hold since our first decade at GIG. I hope this data story conveys a sense of possibility on such cartographies of grassroots innovation and the work behind them, even despite of being done on a voluntary basis, after the rush of energy and inspiration usual in our GIG anual meeting. But there is still a long road ahead, and mapping, interconnecting and enhancing grassroots innovation is an important project by itself in times we are facing (climate and humanitarian crisis, extractivist and colonialist development models of infinite growth in a finite planet, or even the risk of the enclosure of our memory commons with examples like the closing of Twitter and Reddit APIs, among other urgent, exemplary and important problems) as such innovation is and embodied and contextual response to many of the pressing issues we face and an enactive exploration of better worlds seeded into this one. How can we extend, improve and sustain this mapping initiative is still an open question. Hopefully one that we can solve togheter. This data story draf is just a glimpse of the possibilites to come.

# Credits and extra references

This document would not be possible without: - [GIG](https://globalinnovationgathering.org/): for the inspiration and the courage of inhabiting and building different worlds and bringing them, slowly but continuously, into this one. Also for the meetings, the dancing and for the starting site and data collection. - The [Grafoscopio](https://mutabit.com/grafoscopio/en.html) community for the techniques, concepts and prototypes behind was is the showcased here and for the joyful and frienly way to construct them. And [HackBo](https://hackbo.org/), our local hackerspace in Bogotá, Colombia, for being the place of born, nurture and growing of the Grafoscopio community. - The technical communities and people behind [Pharo](https://pharo.org/), [Glamorous Toolkit](https://gtoolkit.com/), [TiddlyWiki](https://gtoolkit.com/) [Fossil](https://fossil-scm.org/) and [Markdeep](https://casual-effects.com/markdeep/), for providing the pieces for our interstitial programming. - [mutabiT](https://mutabit.com/) is a small family research enterprise supporting much of the I+D+i in the development of these techniques. methods and tools. - My family and friends, for giving to me, Offray Luna-Cardenas, the time and focus to write, and for all the support and care while doing that.

There are also several extra references if you want to go deeper in the concepts or techniques behind this data story. Mainly: - [Scraping HTML with XPath](https://books.pharo.org/booklet-Scraping/), the [Pharo mailing list](https://lists.pharo.org/list/pharo-users.lists.pharo.org), the [Pharo Discord chat channel](https://discord.gg/QewZMZa) and the [Pharo Mastodon microblog](https://mastodon.social/@pharoproject). - The [Glamorous Toolkit Book](https://book.gtoolkit.com/) and the [GT Discord chat channel](https://discord.gg/FTJr9gP). - [Grok TiddlyWiki](https://groktiddlywiki.com/read/) wiki book. - The [TiddlyWiki Forum](https://talk.tiddlywiki.org/).

As we can see, grassroots innovation is supported by a wide network of knowledge, care, conversation and documentation and this is particularly visible when is done from the Global South, as without it, innovation would no happen. And as with any list, there are things and people that goes unmentioned. So, thanks again for all the extended network that makes documents and efforts behind posible and fluent.

# Feedback and contact

As you may tell, the main author of this document is not a native English speaker and seems that my English level is not going to get better by having a two weeks top of yearly "inmersion" with hacktivist/academic travels outside my Spanish speaking country and by reading/writing into free open source mailing list and forums.

So, if you have comments and ways to improve this document, don't hesitate to tell me. You can do it in two ways: 1. If the reader knows how to use [Hypothesis](https://web.hypothes.is/), just click in the lateral tab to login and select the text you want to comment on. If the comment is related with corrections or proofreading, please add the tag `proofreading` to it, as illustrated in the following picture sequence:     !!! tip If you are going to annotate with Hypothesis to do some proofreading and/or suggest corrections, please use this [editor's/copwritter's link](https://mutabit.com/repos.fossil/gig/doc/beta/wiki/en/gig-portable-wiki--1apbv.md.html). Hypothesis public annotation branches is another feature of our pocket infrastructures, that we explore more deeply in the [Documentathon](https://mutabit.com/repos.fossil/documentaton/) (in Spanish). 2. You can also write us an email to mailto:info@mutabit.com for sending us private comments or, if you want paid services, prototypes or products, related with learning, using or adapting some of the tools and techniques showed in this document and use them for _grassroots innovation, interactive documentation, agile data storytelling and visualization, digital moldable tools, critical code and data literacy, among other applications_, let us know. **We look forward for productive and creative synergies**.

# License

This document is licensed under a P2P+ License, which, based on the P2P license, is a variation on the Creative Commons Attribution, Share Alike, Non-Commercial License, that allows the distribution and modification of this work with added exceptions for commercial use, if you are an individual, a cooperative or a small to medium business. Click the [Licencia P2P+ (draft 1.0)](https://mutabit.com/repos.fossil/indieweb/doc/trunk/docs/es/p2pmas.html) to read details (in Spanish, translations welcomed). (©) 2020 by Offray Vladimir Luna Cárdenas. The original content of this work is licensed under the P2P Augmented (P2P+) license. You may distribute, modify, reformat and commercialize it under the terms of the [P2P license](.P2P+). of the [P2P license](./p2p.txt), from which it is derived, if you comply with the following conditions: 1. preserve this license notice in copies and derivative works. 2. Belong to any of these groups of persons, for commercial usufruct: a. Any of those indicated in the P2P license, in particular the businesses owned by the workers or the collectives established in the P2P license numeral 4 literal c. b. Being a solo trader, a solo, a micro, a small or a medium enterprise. This clause applies as an exception to clause numeral 4 literal d of the original P2P license. For all other businesses the restriction of the aforementioned clause shall apply. 3. Other distribution or modification agreements have been made with the author.

# Appendix and extra notes

## On the interactive documentation workflow

MiniDocs offers us the possibility to do a web preview of the data narrative as we were writting it.

![ Figure [doc-workflow]: Web live preview at the left of the Lepiter interactive document at the right. ](https://i.imgur.com/HvUXxvW.png)

When clicking the button enclosed in red in figure [doc-workflow], a chromium based web browser is opened (Chrome, Brave, etc), showing a live Markdeep preview of the document, with its enhanced features beyond Markdown (table of contents, equations, admonitions, figure and bibliographic references). This allows a quick way of seeing the exported document outside the GT computer environment, refresh the changes before publishing and sharing our data stories with people who have not GT installed or have it installed in different computers and need a way to synchronize their data stories between them, as MiniDocs exportation to Markdeep includes all the metadata to reimport the document back to the GT computing environment, so it can be reexecuted there (ordered reexecution of the document warranties the objects in the data story have an adecuate status).

## Debugging details

While creating this data story, some improvements and bugs were discovered and fixed in the underlaying software. Despite most being solved, there is also some notes and extra work to be done.

`Tiddler>>nowLocal` has the same functionality that `String>>asDateAndTimeForTiddler`. But the former implementation is buggy and should be replaced by the later. Also, following the [Pharo with Style](https://books.pharo.org/booklet-WithStyle/) guidelines, maybe should be renamed like `asTiddlerDateAndTime`.

If the `Refresh web button` is clicked, and error is raised and some times it is necessary to relaunch the Chromium based web browser, so resynchronization between GT and the live preview can be recovered. This needs to be debugged further to provide automatic relaunching of the web browser or a more descriptive message for the user.

If the `Refresh web button` is clicked when a Hypothesis comment is being made, the Hypothesis sidebar will load the web view of the document, as showed in figure [hyp-preview]. In this case, openning a new tab or restarting the web browser is advised.

![ Figure [hyp-preview]: Hypothesis sidebar showing the web preview of the document. ](https://i.imgur.com/XTAfQSQ.png)