51°F

Aaron Parecki

#indieweb

  • Making Meetable Easier to Install

    Aaron Parecki
    Sat, Jan 18, 2020 3:30pm -08:00

    I've been working towards making Meetable more useful to others by making it easier to configure and deploy. I took a few shortcuts during the initial development that let me finish it faster, primarily by offloading authentication and image resizing to external services. While that's great for me, it means it requires setting up two additional projects if someone else wanted to get it running.

    Today I made a few changes to make this a lot easier for others to install by removing some of these dependencies.

    Meetable now can handle its own image resizing with no configuration! This is probably slower than using the external go imageproxy project, but this way there is no additional setup needed. I even made it use the exact same API, so you can launch Meetable with the built-in image resizing and switch to the external option later.

    I also added a new option for logging in, so users can log in with their GitHub account now as well. It's actually a global configuration option as to whether you want to use the built-in GitHub authentication or the external authentication option using Vouch Proxy, so it's up to the site administrator which one to support. Thanks to some refactoring I did to make this work, it should also be possible to add additional options in the future, such as Twitter login.

    Thanks to these two changes, you should now be able to install Meetable on a wide variety of hosting options! My next project is going to be getting it ready to deploy to Heroku to make it even more accessible!

    At this point, if you're at least a little familiar with Laravel or Composer, it shouldn't be too difficult to set it up! Give it a try and let me know what you think!

    https://github.com/aaronpk/Meetable

    Portland, Oregon • 45°F
    likes 3 reposts 1 bookmark
    #meetable #events #indieweb

  • Meetable: An Open Source Events Aggregator

    Aaron Parecki
    Tue, Jan 14, 2020 10:25am -08:00

    It's been a few weeks since I launched the new events site for IndieWeb events! In that time, the community has already hosted 7 events, and scheduled 15 more! I've continued to push a few minor changes to the site since the launch, primarily around discovery of events with tags.

    The home page now lists a few "significant" tags at the top. These are tags used by two or more upcoming events. 

    This strikes a good balance between having list that isn't overwhelmingly long, and also provides a good experience for discovering events when clicked. I wanted to avoid the case of clicking a tag and finding only one upcoming event.

    I also added a new page "Discover", which for now shows just a list of tags in a sort of tag cloud. I spent some time on the sorting of the list, which places tags used in more than one city up front, and then tags used in just one city are sorted alphabetically afterwards.

    The size corresponds to the number of events with that tag. You can see that they aren't sorted strictly by usage frequency. I think this does a pretty good job of showing tags relevant across a wide geography up front, then narrowing to the more specific city tags afterwards.

    Open Source!

    I had always intended on making this project open source, but I wanted to tidy up a few things before doing that. I initially had an ambitious list of making this an easy out-of-the-box solution at the time I made it open source, but I wasn't able to finish that list in time. Instead, I scaled back my open source goals to at least just have a nice README with installation instructions, even if the installation process still relies on too many moving parts than I am comfortable with.

    Today I am releasing the project as open source under the MIT license! The project is called Meetable, and I've even registered the domain meetable.org to eventually launch a one-page website about the project there.

    There are instructions on installing and configuring it, including full documentation of the config file.

    I've also made a new milestone on the GitHub project for "Version 1.0" where I've collected all the things I want to do before I consider it really usable by others.

    So I hope you will join me in continuing to make this site better! And hopefully it will be useful for other communities as well!

    likes
    #meetable #events #indieweb
  • 🔥(wannabe) breaker of loops 🔥 https://twitter.com/generativist
    The #IndieWeb wiki-docs are excellent.

    Feels like how I wish a lot of api-docs read.

    (h/t @t)

    https://indieweb.org/Getting_Started
    Portland, Oregon • 39°F
    #IndieWeb
  • Vika https://fireburn.ru/

    Microsub specification says that notifications channel should get handled separately from others (that’s why it has a known UID and is the first). Cool feature of Java (and Kotlin) that allows me to do it: I set my Notifications fragment (that is separate from feeds) to a subclass of MicrosubChannelFragment that sets “uid” to notifications. This prevents duplication of code, makes my channels pretty and saves effort!

    Portland, Oregon • 50°F
    #indieweb #Microsub #Kittybox
  • Henrique Dias https://hacdias.com/

    Enabling IndieAuth on my website

    Portland, Oregon • 41°F
    #indieweb #indieauth
  • Charlotte Rose Allen https://twitter.com/CharlieRoseMari
    I think my favorite part of #IndieWeb is the ability to use interchangeable parts. I can post anywhere using a ton of external websites, or my own.
    Portland, Oregon • 37°F
    #IndieWeb

  • Announcing events.indieweb.org!

    Aaron Parecki
    Sat, Dec 21, 2019 1:20pm -08:00

    I'm super happy to announce the launch of a new website for IndieWeb events at events.indieweb.org!

    This website is a place to find and post events for the IndieWeb community. Historically, we've used the IndieWeb wiki to collect events for the community. There are definitely some benefits to this approach, but there are also quite a lot of downsides.

    My goal with this new website was to capture the best parts of a community wiki for events, while streamlining the process for creating events and making it easier to find what you're looking for as an attendee.

    The rest of this post describes the motivations and design decisions for the website. If that is not interesting to you, you can stop reading now, and just know that it should be a lot easier to find and create IndieWeb community events going forward at events.indieweb.org!

    Why do we need a new website?

    Over the last year or so, I've spent a lot of time talking with organizers of the local IndieWeb events like IndieWebCamps or Homebrew Website Clubs. We've also grown a considerable amount this year, adding new organizers and expanding into new cities.

    As we've been onboarding new organizers who are hosting events in their city, I continually see people struggling with the current process of listing an event on the wiki. It's not at all their fault either! Here's an example of what it takes to post a new Homebrew Website Club event, as described on the wiki.

    If your event is not on a "regular" Homebrew Website Club day, then you'll need to add a new date to the wiki template of HWC dates, which means editing this template:

    Create a page on the wiki for the event, the easiest way is to find a past event and copy the page and modify it for your city. That involves editing a page that looks something like this:

    One part of this process that usually gets messed up is that the wiki markup needs to include the h-event Microformats HTML inside the wiki page. This enables some automation that we have, such as generating the IndieWeb newsletter with photos from the event.

    It's far too easy to forget to add a closing </div> or forget the particular syntax for expressing dates and times in HTML and Microformats. I also personally think that it's not very friendly or accessible to make event organizers deal with this kind of low-level markup, and creates a barrier to people who would otherwise enjoy organizing meetups.

    If you have a website that supports posting events on it yourself, then you're also encouraged to create an event post on your own website and link to it from the wiki.

    Then, you need to make sure the event page is added to indieweb.org/Events so that people will actually find it. That also enables some of the automation like having the bot add it to the home page summary and adding it to the newsletter. Thanks to some wiki template wrangling by gRegor, it is at least a little easier to get the wiki markup right since you can use templates for it:

    In practice, relatively few people have actually done this, and usually this ends up being done by either gRegor or Tantek.

    At the end of all of this, attendees are left with an experience for discovering and RSVP'ing for events something like this.

    Visit indieweb.org/Events to see what's coming next, and you're presented with a list like this:

    I'm no designer or information architect, but even I can tell that this page is lacking in some very basic structure that would make it friendly to viewers.

    If you manage to find a meetup in your city and click on it, then you visit the event page for the full details.

    This now presents its own list of challenges.

    • The "When" section at the top lists a time range, but in reality each location sets their own times so you have to double check below
    • You have to scroll through several other cities listed on the page to find the details for the one you're looking for
    • There's just a lot of visual clutter here, largely due to being constrained by the wiki environment

    So needless to say, this is not a very good experience for event organizers or attendees.

    We've talked about trying to improve this situation at various organizers meetups in the past, but never came up with a conclusive plan. I decided that it would be my personal goal to launch a new website to solve these issues so that we can go into 2020 with a much nicer experience for events.

    I am happy to say I believe I have addressed nearly all the issues with our current system, while still making it as flexible to use as the wiki.

    Here's a quick overview of roughly the feature set of the new events website.

    Finding Events

    List of upcoming events - the home page is a list of all upcoming events

    Archive pages - past events can be found by browsing a year page or month page.

    Tag pages - events can be tagged, and tag pages show all events with that tag! This can be used to create city pages showing events only in that city, for example: #austin.

    iCal feeds - every page has an iCal feed you can add to your calendar! You can add the home page iCal feed to get a list of all events, or you can add a tag page feed to get just events in your city.

    Microformats - of course every page is marked up with h-event Microformats, so you can subscribe to this in software that supports that vocabulary, or use it as an API for getting events from this website for things like the IndieWeb Newsletter.

    Authentication - if you're logged in to the IndieWeb wiki, then you're already logged in here!

    Wiki-like editing - anyone who is logged in can add and edit all the details of events, just like if it were a wiki page.

    Events have their own permalinks which have the following features:

    Cover image - events can have a cover image that shows up at the top. These are always cropped to a fixed size for consistency.

    Photo gallery - photos can be added to the event page, and they show up as a nice photo gallery. The first photo is shown full width, and then below that is a grid with the rest of the photos.

    The photos can be clicked to view larger, and you can also add alt text for the photos as well. The photos can be re-ordered by dragging them around if you're logged in.

    You can either upload photos to the event directly, or you can add photos by posting them on your own website and sending a webmention to the event page!

    Related blog posts and comments - event pages can show related blog posts about an event, which is a fun way to capture what people have written after an event. See IndieWebCamp Amsterdam 2019 as an example. If you want to add your own post to an event, just link to the event page and send a webmention!

    RSVPs - RSVPs are handled in two different ways. If you're logged in, you'll see an "I'm Going" button on upcoming events. You can click it to add yourself to the RSVP list immediately. The event pages also accept RSVP Webmentions so you can RSVP from your own website.

    HTML and Markdown description - the main page for the event supports Markdown and a limited subset of HTML tags for formatting. You can use this to provide full details of an event, or even add things that aren't otherwise supported by the website.

    Add to calendar - every upcoming event has an "add to calendar" button which provides both an iCal event as well as a like to add to a Google calendar.

    Timezone converter - for events that have a specific start time, the time links out to a page that shows that time in multiple timezones. This is mainly useful for virtual events like Virtual Homebrew Website Clubs, or if you're trying to remotely join another event.

    The time of the event is shown along with the time of the event in the timezone your browser reports. Below that is a list of the equivalent times in all timezones used by other events in the website.

    URL Design

    One of my main goals with the event URLs was that I wanted them to be meaningful to humans. This means communicating some context about the event from the URL alone.

    That means avoiding the URL patterns from Twitter and Instagram which are just a random string.

    I opted to go with the pattern: YYYY/mm/slug-id. This conveys a rough approximation of the date of the event (year and month only). The slug is a generated slug from the name of the event, converting everything to lowercase and removing non-alphanumeric characters, separating words with hyphens. The id portion is a unique identifier for the event which doesn't change after it's created.

    If a post is updated to have a new name, a new slug is generated. Because the permalinks only rely on the unique ID, it doesn't actually matter what your enter for the year or month or slug portion of the URL, you're always redirected to the canonical based on the ID in the URL.

    The only thing about this that I'm not entirely happy with is the random ID at the end. I feel like it's taking the easy way out with URL routing at the expense of being friendlier to look at. The upside is that a lot of technical challenges become a lot easier doing it this way, I don't have to store a list of past slugs to support redirects for example, so I thought it was worth the tradeoff in this case. I put it at the end because when a portion of the URL is shown in Twitter or Slack for example, you'd be able to see the most meaningful parts of the URL even if the end is cut off.

    Creating an Event

    I wanted creating an event to be as straightforward as possible. To start with, there's a giant "Add an Event" link in the top navigation bar, which is already an improvement.

    One challenge I quickly ran into was that adding fields for all the information needed about the event quickly turns into quite a large form. I didn't want to split it into multiple pages, so instead I broke the page into sections.

    To start, you enter the name of the event, and optionally add a cover image. The image will be cropped and a preview will appear immediately.

    Next, you'll add information about the location of the event. Ultimately these are just regular text fields, but the "search for a location" box on top can help you automatically fill them out by looking up a location.

    If you start typing in that box, it will use the Google Maps autocomplete API to find venues matching your search.

    Clicking on one of the options in the list will then fill out the details in the rest of the fields, and you'll see a little map appear as visual confirmation.

    Of course you're free to not use the venue search at all and just type in the details manually. Or for virtual events with no physical location you can just enter "Online" as the venue name.

    Next up is adding the date and/or time of the event.

    If you do use the autocomplete and select a venue, then an additional bonus is that it finds the matching timezone for that location as well.

    This is where it gets a bit tricky. I've made a couple of design decisions around date handling to simplify both the data entry as well as presentation of dates and times for events. I'll describe those in detail a bit later.

    Lastly, you can add a link to the event's website if it has one, add a description, and add one or more tags.

    You'd want to include a link to the event's website if for example it requires that you register for tickets to attend the event. Since IndieWebCamps require ticket registration, we'll be linking out to the individual IndieWebCamp's page to buy tickets. We've been using a pattern of YYYY.indieweb.org/city for a few years now, and it's worked out pretty well. But if you're adding something like a Homebrew Website Club that doesn't have its own website, you just leave this blank and this page effectively becomes the canonical link for that event.

    The description field supports markdown and a limited set of HTML tags for formatting. For events with their own website, I'd recommend leaving this description relatively short. But if you want this page to be the canonical event page, feel free to use multiple headers, embed images, and make it look as nice as you want.

    Tags are a great way to collect related events so they can be found easier. I'd definitely recommend adding a tag for the city of the event, such as "austin", so that people can then visit the tag page to find events in their city. You can also add tags like "indiewebcamp" or "hwc" which then provide a quick way for people to find all upcoming Homebrew Website Clubs regardless of location.

    Clone event - in order to support quickly adding recurring events like Homebrew Website Clubs, you can click the "Clone Event" button on a previous event, and quickly make a new event by changing only the details you want.

    Date and Time Handling

    Deciding how to handle dates, times, and timezones was one of the most challenging parts of this project. If you've ever dealt with building systems that handle times and timezones you'll know what I mean.

    I decided to have essentially four distinct ways an event can present its date/time on this website.

    One-day events - an event that takes place during some portion of one day. This is intended for things like evening events, one-day IndieWebCamps, or other full-day conferences. To create this event, enter only the start date, and enter a start and optionally enter the end time.

    Depending on whether you enter a start and end time, the event date will be displayed as one of the below:

    If you don't enter a timezone, then these times are considered "floating times" or "local times" and the system doesn't know when it actually occurs. The iCal feed that it produces will also output it as a floating time, leaving out all timezone information. Calendar apps should add this as either a floating time in your calendar, or snap it to your local timezone when you add it. That can cause some edge cases such as when you add an event in the future that will be in a timezone different from where you are when you add it.

    If you add a timezone when you create the event, then it will display the timezone there as well as include it in the iCal feed, and you'll avoid the floating time issues.

    Multi-day events - an event that spans more than one day, such as multi-day conferences.

    I took the liberty of deciding that in this case, the times of the event are never shown. In practice, I find it to be more confusing than helpful when an event is shown as being "January 20, 8:00am through January 21, 5:00pm". Does that mean I am expected to be there overnight? What time do things wrap up the first day? etc. etc. Instead, it's far more helpful for the overall date range of the event to be displayed at the top, and then elsewhere provide the detailed day-by-day schedule. This is how we've handled it with our pages like IndieWeb Summit which show the date summary at the top and a detailed schedule grid below.

    So to create multi-day events, you only need to enter the start and end dates. Even if you enter times, they will be ignored by the system. The timezone is also unnecessary in this case because it's not needed in order for something reading the feed to show the same date range.

    That will be displayed without any time or timezone information.

    If the date range spans a month boundary, then both month names appear of course.

    In this case, the iCal feed also omits the times and timezone. That means adding it to a calendar app adds it as a floating date. I've had Apple Calendar and Outlook both mess up multi-day events when there's a timezone specified, so that it looks like the event starts at 5pm local time the previous day, which is really confusing. This should prevent that from happening.

    Open Source

    My goal is to eventually open source this project so that others can use it for their own community. I'm actually planning on running a copy of it on oauth.net to collect OAuth community events as well.

    That said, I feel like it's not quite ready to open source, so I'm holding off on that for the time being. Here are some of the things I need to solve before I'm ready to publish this.

    • Create a web installer - I'd like the installation experience for this to be more like WordPress and not require command line configuration. The installer should walk you through checking system requirements, setting up the database, etc.
    • Drop dependency on go imageproxy - The go imageproxy that this uses for quickly resizing images is great, but it's a barrier to setting this project up. This project should download and resize images it needs and serve them locally.
    • Add authentication options - Right now the only authentication option is looking at the HTTP Remote-User header, which is a great way to tie this in to existing authentication systems. I'll need to provide alternatives for people who don't have an existing authentication system already.
    • Theming/Styling/Customization - The design of this project is intentionally minimal, my goal is to allow some flexibility in styling it to match an existing website. I'm not sure what form this should take (WordPress themes are way more than I want to do), but some amount of customization is necessary.

    Replacing the use of the IndieWeb wiki for events

    My goal is to not have any 2020 events on the IndieWeb wiki! I think this project is far enough along that it can effectively do everything the wiki can do around events and more.

    I've already added all the upcoming 2020 events that were on the wiki into the new website. Going forward, it should be significantly easier adding events on this website rather than the wiki. There will only be a little bit of cleanup to do around some of the automations such as the list of upcoming events on the home page and the newsletter.

    I'm sure there are some things I forgot to address while building this, so if you're an organizer of any IndieWeb events, please do let me know what I may have missed.

    So let me know what you think! I'm really excited to have finally launched this after spending so long designing and building it. Thanks to everyone who helped me talk through the early prototypes of this idea. I'm hoping it makes for a much better experience for everyone who hosts and attends IndieWeb events!

    likes 6 replies 3 mentions
    #indieweb #indiewebcamp #events
  • Vika https://fireburn.ru/

    i don’t care if twitter is down tho cause I just use my website to post stuff! #IndieWeb #ownyourdata

    Portland, Oregon • 40°F
    #IndieWeb #ownyourdata
  • name.com https://twitter.com/namedotcom
    Not sure if you've heard of #IndieWeb, but it's that notion that you should be able to keep your own content in your control. Join the group and share your solutions to decentralize the web. https://indieweb.org/
    Portland, Oregon • 48°F
    #IndieWeb
  • https://jgregorymcverry.com https://twitter.com/jgmac1106
    Huge shout-out to @mblaney who just added Domain registration to @ihazawebsite https://i.haza.website/ with the help of @namedotcom, long time #IndieWeb supporters (https://quickthoughts.jgregorymcverry.com/s/uJxOx)
    Portland, Oregon • 39°F
    #IndieWeb
  • Twitter to decentralize… something (www.manton.org)
    Portland, Oregon • 46°F
    #indieweb #twitter
  • Jonathan LaCour https://twitter.com/cleverdevil
    Hey, @jack, I’d like to nominate @aaronpk and @t to lead @bluesky, perhaps with an assist from @benwerd. They’ve got quite the head start with the #IndieWeb!

    By the way, I posted this via my own website... how decentralized of me!
    Portland, Oregon • 46°F
    #IndieWeb
  • Firefox 🔥 https://twitter.com/firefox
    We have thousands of open source architects, engineers, and designers who have been contributing to decentralization & building community (like #indieweb) over the past 15 years.

    It's safe to say we're extremely invested in the free and open internet, so we're here to help.
    Portland, Oregon • 49°F
    #indieweb
  • Kevin Marks https://twitter.com/kevinmarks
    Hi chaps, we may be able to save you a lot of effort, as we already have a set of open standards developed by the #indieweb community and standardised through w3c - micropub, webmention, websub and more in development with microsub too http://chat.indieweb.org for more
    Portland, Oregon • 43°F
    #indieweb
  • Aaron Parecki
    Thanks to @marinintim we now have a Russian translation of IndieNews! Check it out and submit your Russian posts at https://news.indieweb.org/ru
    Portland, Oregon • 42°F
    1 reply
    #indieweb #indienews
  • Anders Borum https://twitter.com/palmin
    I make apps that I think would appeal to people in the #indieweb community, but how can I advertise that these apps exist?

    They are obviously not using ad-tech but the websites and podcasts run without sponsorships.

    Any ideas?
    Portland, Oregon • 43°F
    #indieweb
  • In the Beginning was the Website (desmondrivet.com)
    "Even if the entire IndieWeb consisted of a single personal website, it would still "work", in the sense that the owner of the website would be in control of their own content and would still be able to share that content with their friends"
    Portland, Oregon • 47°F
    #indieweb
  • 🌬(wannabe) breaker of loops ☃️ https://twitter.com/generativist
    #indieweb is cool

    That’s it. That’s the whole tweet.
    Portland, Oregon • 44°F
    #indieweb
  • Vika https://fireburn.ru/

    Proposal for #IndieWeb website swap day/week/event

    Portland, Oregon • 45°F
    #IndieWeb
  • brentsimmons https://micro.blog/brentsimmons   •   Dec 5

    @manton I’m still not quite sure why it wasn’t a good idea!

    Aaron Parecki
    Two reasons:

    1: The only data in the Pingback payload is two URLs. Wrapping this an an XML container that's also doing RPC is incredibly overkill for sending just two values. That's why Webmention went with form-encoded instead, like regular HTML forms, which is about the most compact way you can send two values.

    2: Pingback never went far enough with the user experience of displaying them. At best, you'd see a snippet of the text near the link, which it turns out wasn't really that useful or contextual. Once social media started taking off, the interactions there became far richer than seeing the pingback excerpt, so people abandoned them. With Webmention, we're explicitly focusing on enabling the kind of rich interactions people do on social media instead.
    Portland, Oregon • 52°F
    #pingback #webmention #indieweb