Add Workshop Pages

[NitramLegov]

We should add a page for each of the workshops (electronics, wood, metal), the common room, the outside area and the comaking room.

The page should contain a little bit of text and some pictures

[LukasFreeze]

I'd prefer a single "Ausstattung"/"Equipment" page rather than separate ones for each section - those would look pretty empty in my opinion... Suggestion: panorama shot of each workshop as a horizontal divider, followed by a captioned gallery of tools (each picture linking to the wiki?). If it becomes too much, we could still split it up later :-)

…

On May 18, 2019 8:23 PM, "NitramLegov" ***@***.***> wrote: We should add a page for each of the workshops (electronics, wood, metal), the common room, the outside area and the comaking room. The page should contain a little bit of text and some pictures — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#8?email_source=notifications&email_token=AEWXG2YWN7V33FY5FF2MUG3PWBCSVA5CNFSM4HN22NGKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4GURPHVQ>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEWXG27Y7UB3TNIGEITNFGDPWBCSVANCNFSM4HN22NGA> .

[NitramLegov]

We could set up a github action to automatically fetch the machines and tools from mediawiki using the API.
The data fetched should be readable by jekyll and it should be able to further use it on the different sites.

I have set up such an action in https://github.com/comakingspace/comakingspace.github.io/blob/main/.github/workflows/main.yml

The action has been tested in a private repository of myself and works. However, it can currently not push to this repository since we have protected the main branch in a way that only administrators can push commits directly. This does not include github actions.

Does anybody have an idea on how to overcome this?

As an alternative, I would be willing to have the GitHub Action create pull requests and then accept them. However, this would require the action to only update the files in case there are changes. This might require some bash magic, since we can not just compare the API results to existing files (the API returns some runtime data which will change with each API call).

[NitramLegov]

A first draft can be seen on https://www.comakingspace.org/metal_workshop/

(so far, this is excluded from the sitemap btw)

[NitramLegov]

I have added further workshops and an overview of the tools based on the wiki. A link to the specific workshop pages can be found here:
https://www.comakingspace.org/workshops/

Feel free to take a look :)

Personally, I think including the "Tools" does not make a lot of sense. I would rather limit it to the machines (at least as a first step).

[LukasFreeze]

Personally, I think including the "Tools" does not make a lot of sense. I

would rather limit it to the machines (at least as a first step). I agree: only the machines should be enough, especially since many of the tools will be "standard" ones that do not persuade anyone to visit. We could link to the entire list in the wiki for really curious people, but I would not put the small stuff on the website or it's way too crowded.

We could set up a github action to automatically fetch the machines and

tools from mediawiki using the API.[...] Hopefully I understand this correctly, otherwise the following may not be relevant ;-) While it would theoretically be really cool if we could manage frequent automatic generation, I think that may cause more problems than it solves. How about just grabbing the content from the wiki once [or once a year, if needed]? We do not change our machine selection (or even the photos) that often, but I'm afraid there are some differences between wiki and website requirements that lead to manual corrections every time the workshop pages are created anew. Specifically, I see these problems: - in the wiki, it was argued the galleries should list the specific machine (e.g. "CMI C-S-BS 250") instead of the type (e.g. "bandsaws") when not all machines of the type are in fact in the same area. I'm still not a fan of that, but can live with it in the wiki...but on the website, it's really ugly! We should at least change the names in those cases; photos could of course still show the "correct" machine. - translation: German machine names on the website will arguably lead to way more interest, so we should make German versions of these gallery pages. That's probably rather hard to do automatically (unless we add a new SMW property to every wiki page), but really simple to just type in the website source code in one go. What do you think?

…

On Tue, Apr 27, 2021 at 12:20 PM Martin ***@***.***> wrote: I have added further workshops and an overview of the tools based on the wiki. A link to the specific workshop pages can be found here: https://www.comakingspace.org/workshops/ Feel free to take a look :) Personally, I think including the "Tools" does not make a lot of sense. I would rather limit it to the machines (at least as a first step). — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#8 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEWXG26FIKJSGRBHUOGVSQDTK2FVFANCNFSM4HN22NGA> .

[LukasFreeze]

Another suggestion, as the auto-generation would of course be really awesome for the photos when someone starts to make cool new ones: can we just separate photos and titles in some way, and keep the manually written text as dominant info when the content is re-grabbed from the wiki?

[NitramLegov]

I agree: only the machines should be enough, especially since many of the tools will be "standard" ones that do not persuade
anyone to visit.

Awesome. i will remove the tools with one of the next updates.

but I'm afraid there are some differences between wiki and website requirements that lead to manual corrections every time the workshop pages are created anew.

Hmm. While huge parts of the wiki of course have different goals and thus requirements than the website, I would see the galleries (Like implemented on https://wiki.comakingspace.de/Wood_Workshop) having similar requirements as the website: show new users the machines that can be used in our makerspace :) Therefore, I think they should follow a similar generation logic :)

Quick explanation of how it is implemented currently:
From the wiki, I am using the API to select pages with the corresponding Location and with Category Machines / Tools. From these pages the API returns the Properties "Has Image" and "Has Caption" (Though honestly I am ignoring the "Has Caption" property).

The Workshop pages are generated entirely automatic out of data received from the mediawiki API. No manipulation of the data is done. It is just being stored in a file (see https://github.com/comakingspace/comakingspace.github.io/blob/main/_data/Workshops/ERoom_Machines.json as an example).
This data is then used to automatically generate the workshop pages. The only thing I have not automated so far is updating the content on a regular base (though large parts of this are also implemented already, I just can´t push it to the repository so far)

The name of the machine that gets displayed on the website is basically the name of the corresponding wiki page. The image you are seeing is actually distributed right from the wiki. It is not even stored on our website :)

Manual Changes on the website?
With the current setup, there is only one point where we could manually manipulate the data: right after downloading it from the wiki. However, since I am using the plain output from the mediawiki API, this would be quite nasty and need to be redone every time we update the data.

I would very much like to keep this setup, since it is really simple and straightforward and does not require manual interaction :) However, I would be open to introducing some new property in the wiki and/or change the way the captions are generated.

in the wiki, it was argued the galleries should list the specific machine (e.g. "CMI C-S-BS 250") instead of the type (e.g. "bandsaws") when not all machines of the type are in fact in the same area. I'm still not a fan of that, but can live with it in the wiki...but on the website, it's really ugly! We should at least change the names in those cases; photos could of course still show the "correct" machine.

The galleries in the wiki and the workshop pages on the website in my opinion have very similar goals and should ideally be generated following a similar logic. While I entirely agree with the names of the machines being more critical on the website than in the wiki, I would also argue that we should change the logic in the wiki as well. I´ll think about this :)

translation: German machine names on the website will arguably lead to way more interest, so we should make German versions of these gallery pages. That's probably rather hard to do automatically (unless we add a new SMW property to every wiki page), but really simple to just type in the website source code in one go.

Very good catch! Since there is no step in the generation of the website that allows for manual interference, the most easy solution would be the one you have proposed: Adding an extra SMW property. Let´s think about this.

[NitramLegov]

For a technical demostration, I have set up an english and german overview of the machines in our wiki:
https://www.comakingspace.org/workshops/ Gives the links to the english pages
https://www.comakingspace.org/werkst%C3%A4tten/ to the german pages

Additionally, there is an automated sync from the wiki to github pages which runs daily at 8am. It only updates the website if there have been changes.

Managers can also trigger the workflow manually in Slack.

@LukasFreeze Can you take a look and let me know what you think about the way I have set it up? Especially since we have made our changes to the wiki structure regarding the Machine Types and German texts in the meantime

Once we agree on the general technical setup, we can start making it nice on the website (bring it all to one page with some horizontal separators)

[LukasFreeze]

I like the design! Of course it now shows which photos need improvement and which German names are still missing, but that's just motivation to improve the data :-) Is it possible to order the German pages by German names instead of (invisible) English ones? And I still think we should filter a bit, nobody cares about 4 different cordless drills, 4 different shop vacs or machines like a spin dryer or flatiron on this level. Would a new SMW property like "website-exclude" make sense? I suppose you still don't like "extrabox", and we might want to stay more detailed in the wiki galleries than we need to be on these more "public" pages ;-)

…

On Wed, Jan 17, 2024, 23:49 Martin ***@***.***> wrote: For a technical demostration, I have set up an english and german overview of the machines in our wiki: https://www.comakingspace.org/workshops/ Gives the links to the english pages https://www.comakingspace.org/werkst%C3%A4tten/ to the german pages Additionally, there is an automated sync from the wiki to github pages which runs daily at 8am. It only updates the website if there have been changes. Managers can also trigger the workflow manually in Slack. @LukasFreeze <https://github.com/LukasFreeze> Can you take a look and let me know what you think about the way I have set it up? Especially since we have made our changes to the wiki structure regarding the Machine Types and German texts in the meantime Once we agree on the general technical setup, we can start making it nice on the website (bring it all to one page with some horizontal separators) — Reply to this email directly, view it on GitHub <#8 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEWXG27S7LP3D2RFVOZHNVDYPBIOLAVCNFSM4HN22NGKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBZG4ZDKNJSGEZQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[NitramLegov]

Great. I have streamlined the wiki extract a bit and with that I was able to implement sorting by german names :)
The Machines without a german text are located at the end of the list. I can switch that to the beginning, but thought it looks a bit nicer this way.

Regarding the exclusion of machines: I agree that we have a need to filter the machines. As you said, nobody cares about 4 cordless drills at this level.

However, the extrabox parameter would indeed not be the right one. The way we are currently using it is to ensure that MachineTypes are not added to Category:Machines 🙈
https://wiki.comakingspace.de/Special:SearchByProperty/:Has-20extrabox/Yes <-- See the current usage here

To be fair, "extrabox" is currently a bit misleading as a name. It might be worthwile changing this, but that´s a different discussion 😅

I´m open for a parameter "website-exclude" or similar. Just as a general remark, let me point out my thoughts regarding the technical implementation:

In semantic mediawiki, we cannot query for the absense of a property. Thus, if we only set the property on pages to be excluded, I would need to query for all pages and then remove those with the exclusion property from the result. This is possible in our workflow, but would be harder to do if we want to use the property for anything within the wiki itself.

I can also implement a property "website-include" which is always set on pages with a MachineInfoBox (default:yes). There can be a template parameter called "website-exclude". If the parameter is set, the property will be set to "no". This way, we can use the property also within the wiki if needed. Let me know your thoughts

[NitramLegov]

I have now implemented the following:

• If no german name exists, the english name gets used (not sure how much I like this, but it´s an easy change to revert)
• Duplicate machines (identified by "Caption") will be removed. It is a bit random, which machine gets used, but overall this should be fine.

@Narquadah @Pakue95 would you be willing to invest some time in styling the pages? I personally think using round pictures is not really good for representing machines. I just copy-pasted this from the team page 😅🙈

[Pakue95]

I'll have a look during the weekend

[Pakue95]

New design is up 12df2ae. Let me know if it works for you.

[NitramLegov]

Thanks to @Pakue95 for the new design! I personally like it, so I merged it to the main branch.

Now we still have to decide on how to structure the Equipment overview on the website. I have created a set of examples and would like to ask you for your opinion:

1. Seperate pages for each workshop (With an introduction page: https://www.comakingspace.org/workshops/)
   1.1 Woork Workshop: https://www.comakingspace.org/wood_workshop/ & https://www.comakingspace.org/holzwerkstatt/
   1.2 Metal Workshop: https://www.comakingspace.org/metal_workshop/ & https://www.comakingspace.org/metallwerkstatt/
   1.3 E-Room: https://www.comakingspace.org/e-room/ & https://www.comakingspace.org/elektronikraum/
2. One large page with all machines, seperated by workshop:
   2.1 German: https://www.comakingspace.org/ausr%C3%BCstung_getrennt/
   2.2 English: https://www.comakingspace.org/equipment_separated/
3. One large page with all machines and no seperator by workshop:
   3.1 German: https://www.comakingspace.org/ausr%C3%BCstung_gesamt/
   3.2 English: https://www.comakingspace.org/equipment_all/

Just to add my thoughts to this:
If we separate the machines by workshop, there are a few things I´m not super happy with. For instance, the CNC Mill is assigned to the Wood Workshop (but can be used for metalworking) and the airbrush compressor is assigned to the Electronics Room (but has nothing to do with electronics). This makes me think that option 3 might be the best. However, option 3 can be overwhelming for visitors, since there is no structure at all.

What do you think? Of course, we can also implement a mix of different versions if somebody has a good idea :-)

[NitramLegov]

Since perfect is the enemy of good, I have created a version where the different workshops can be opened and collapsed.

I have also included this in the header navigation and into the sitemap :-)

Improvements can of course still be implemented, but I believe it is suitable for a first public version.