Today I attended my second London Homebrew meetup. There was a couple of interesting discussions there. Here are some of my notes about it (I skipped the demos info and probably still missed some topics):
One of the topics was testing website for mobile. I found out, that in some browsers' dev tools, there is a way to test for different viewport sizes. But multiple people described their process. One even showed multiple devices.
My regular testing is only in my browser. Every couple of month I click though my website on my old tables with default browser (so whatever shipped with Android 4.1) and in the text based browser like lynx.
My philosophy is, that if it works alright on these two, then it would most likely work everywhere. And I did not really put any time in the design yet.
Connected to the upper point, there was also a short discussion about the image optimization - how to make both pictures look better on mobile and have smaller pictures.
There were services like Image Optim for Mac.
This only reminded me, that I needed to finish the blog post about the ecology of my website, that I started way too long ago. There are still some parts of it, that I did not even started on - like optimization of images.
Sync reactions data
The interesting topic was then opened. For social readers, how to we sync the likes, bookmarks and replies, without relying on the centralized services.
So the problem is sort of like this: when one browse the entries in the social, it would be nice to have it seen, which entries were already linked, bookmarked, replied to (or also read). Or at least, if somebody tried to like or bookmark something, it would not create a duplicate post for this.
This data is available in the websites, but it would require the scraping of entire website (could it be just partly? Not sure) each time. This would noticeably effect the time required to load page.
Also, if saved locally, then how to deal with deleted bookmarks or likes?
There are situation specific solutions - like check in the database, that would work for that specific case only. But there is no distributed solution. These seems to be harder, because it is not possible to just stuck it in the database.
I had some ideas after the meeting. None that would work universally.
One would be, that if the person shows webmentions on the page, these could be parsed to check for this. But I am not sure, if these are always shown with consistent markdown. In worst case, checking links back to the site or data in h-cards could work as an indication as well. Not what was specifically done, but that something was done. Not sure how to deal with the mentions of people inside of the post in this case.
The second would be, that this data would be provided by scraping one page only - sort of like sitemap for bookmarks and likes. But this would depend on adoption, so it seem like an even worse idea than above.
In a more scoped down case, how to make sure, I do not have multiple same likes or bookmarks on my page is more tractable. In this case, the person publishing would need to have the ability to filter out the ones, that are already on the page.
Non-tehnical people in IndieWeb
The discussion then turned to non-technical people in the IndieWeb. The topic already started with the previous topic, since this would be the experience, that people coming from the silos like Facebook will be expecting.
One of the first conversation points was, how to convince people to join IndieWeb. I shared, that the only way I managed to get some interest (but no conversion yet), was to tap into the feeling of how they likes having their own blog in high school days. The other interesting point of view, that was shared was the data privacy.
The conversation then came to how easy is to understand the IndieWeb from the main page and wiki. The sentiment that wiki is not easily understandable for new people. I agree with this, because this was also my experience on the first contact with the IndieWeb wiki.
We then moved the discussion to the main page of the IndieWeb website. The interesting comment was, that the main page did not change in years. This can confuse people coming back, if this thing is even still alive.
Apparently it also looks old, and this might put of some people. So simply changing the design could have a positive effect. I am not a designer and the look would not put me off, so I will trust the other people's judgment on this.
Some helpful examples were offered, like the Mozilla Developer Docs or UK governmental site (from common notes UK Government Digital Service and UK Service Manual).
There were also interesting projects inside IndieWeb, like IndieWeb Guides, which try to provide steps to get one started.
We then moved the discussion of how to non-technical people find about the IndieWeb. The people on micro.blog are all part of the IndeWeb. But they most likely did not join the IndieWeb by going through the IndieWeb website. They joined micro.blog .
We compared the notes on how we joined the IndieWeb, and one think that I noticed is, now important was the community in this process. I did not really take IndieWeb seriously until I attended IndieWebCamp. Another person found about it through Beyond Tellerand conference, where IndieWebCamp was run as the side event. Yet another talked about the importance of people in the chat, when starting out.