[kevinmarks][aaronpk] - monocle ui suggestion - put the backlink into the title area for the channel rather than atop the content so you don't have to scroll back up to go back
voxpelli_, ingoogni, [tantek], krychu, [Rose], [dougbeal] and [jgmac1106] joined the channel
[eddie][grantcodes] If you are around I an very curious about your thoughts here: https://github.com/indieweb/micropub-extensions/issues/11#issuecomment-483658170 the idea of having some vague "not set" visibility seems really not user friendly. For a technical audience I think we can understand what "not setting" a property can do with the server defaulting things, but I don't know that a non-technical user base is going to feel comfortable with that.
[grantcodes]Not sure I agree with you, based mainly on the idea that still the majority of clients will just use content=whatever and not send anything about visibility so the user will have to know their defaults anyway
[eddie]I really think as more users join the IndieWeb and more of them are less technical, clients that require the user to know things like their server defaults will overwhelm or scare non-technical users away leading towards the majority of clients being used having user friendly options
[eddie]so I'm sure clients will stick around without things like visibility, but I think the majority used will likely end up with things like that because self-selecting usability
[eddie]Gotcha. So I conceptually agree if you have a dropdown that defaults to "Public" (because the server said that was the default visibility) you wouldn't HAVE to include visibility=public in the request
[eddie]I just think with things like visibility/privacy, if a client supports visibility, it is helpful to be better safe than sorry by both providing a UI that says the visibility (even if it's a default visibility) and then when sending a request, including that string in the Micropub request
[grantcodes]My issue is more to do with the fact that everying is decentralized means we have to always assume there will be clients that will not send any of this default stuff, and just use the bare minimum. So it needs to be designed with this in mind.
[grantcodes]I agree that it would be good practice to show the user their default server settings in a client, but if there are still clients that don't do it the user will need to know their default.
[eddie]I think ultimately, a user will know/learn their default, or if they have a bad experience with a client that doesn't support visibility, they won't use it again
zoglesby, myfreeweb, grantcodes[m], astrojuanlu[m], plindner[m], ketudb[m], voss[m], Rixon, jamietanna|wwwjv, jgmac1106[m], PatrickMNiedziel, ludovicchabant and jackjamieson joined the channel
[eddie]* There will always be clients in the wild that don't support visibility, in those cases the server MUST default visibility to whatever it deems appropriate.
[grantcodes]I think there are probably lessons to be learned from headless cms's and the likes that generate a ui from a schema of sorts. That is pretty close to this idea
Loqi[EdwardHinkle] So initially brainstorming this: you definitely don't want to simplify the syndicate-to object because that is needed. I also don't know that you would want to complicate the category array by making the strings be objects, because then you're just a...
[eddie]hmm interesting. I thought about all options being an object with both a value and a name, but then it seemed duplicative for things like categories, but maybe it's not that bad since categories is really technically big enough it probably still needs to be in it's own query
aaronpkrather than try to define a whole schema thing that solves all possible use cases, can you point to a specific issue that your'e having with the existing landscape and make a suggestion that could address just that issue?
[eddie]so the issue brought up by [grantcodes] was that dealing with syndicate-to values, categories and visibility are all very different data structures currently
[eddie]I think the concern is we're starting to add more and more properties and values and the more we add if each one is it's own unique snowflake, that causes issues
Loqi[grantcodes] So I think there are at least 2 ways we would need to show full support for a property:
1. The basic property is supported and accepts any value, e.g. things like `summary` and `category` can accept pretty much anything, but would be nice to know ...
aaronpkultimately the UI is going to treat all these properties completely differently anyway, so i don't see why making a schema to tell the client what kinds of values are supported that also is consistent with itself helps at all
[eddie]That's fair. It was just a brainstorm based on his github comment. If we feel this is too heavy we can just look at listing supported properties and returning things like the default
[eddie]so in that thread 1) A client should only present UI for properties that a server support 2) A client needs to be able to show the user predefined options as well as show any defaults the server will do (like the default visibility)
[eddie]I think the things such as if new value are supported or multiple values are supported is more an optimization so that instead of writing code that only matches "if syndicate-to" instead you can write code for if multiple values accepted
sknebelI add new properties to my micropub endpoint, or use one that has properties not all clients support, but I want to use existing (ideally the same) micropub client(s)
aaronpki would never expect a client to be able to make up a UI for properties it doesn't know about. That's like form generator territory and is not a sustainable plan
[eddie]because I think those are the absolute priority of that github issue. hiding unsupported fields and having the data and defaults for the supported ones
[grantcodes]I think what eddie has proposed is where it all may end up, if all the different valid issues are merged together, althought a bit of a leap to go straight there
aaronpkHere's an example of where form generator territory falls on its face. Show me any modern app that lists the text "public" "private" "unlisted" in its UI. More often it's indicated by some sort of icon. Look at twitter and Swarm for easy examples. There's virtually no way to reliably do that in a way where clients can show that UI when they weren't written to support it natively
[eddie]if anything it would be do your UI the way you want for known properties and include a small section at the bottom that can include any not currently known and optimized fields
sknebel(and I'm assuming aaronpk is defining anything that contains a form generator as "not modern" :P ... but again, if I'm looking for "I want use my private posts implementation without handediting data files", "not modern" will do just fine)
[grantcodes]I think aaronpk is thinking more of silo type posting interfaces, whereas I am thinking more of a cms type interface, the majority of which can absolutely can be managed by a form generator
[eddie]it would be much nicer if most Micropub apps had an optional area at the bottom that might not look the best, but had a list of channels that I could select and be sent back to my site
[eddie]sure, there will always be exceptions, but that doesn't mean we should have some flexibility in a server telling a Micropub client about it's own simple data it would like back
[grantcodes]I'm not sure defining what sort of ui is good or bad for clients is useful for the spec though. Is that not kind of the point of being able to use different clients? Different strokes for different folks and all that
[grantcodes]I think a better example is not your own personal property, but all the experimental ones that multple people support, like visibility, post-status, location-visibility. All that stuff is implemented by a bunch of people, but then there are very few clients that support them.
[eddie]But is the idea of a fallback so bad? You know about 3 out of 5, so you treat 3 out of 5 the way you know and you fallback the 2 unknown ones to a way that is functional?
[eddie]however I think apps can built UI that fits the platform that matches a few basic criteria. For example: predefined options with multiple selections? Quill's syndication list. Predefined options with new values allowed? Quill's tags text field with autocomplete. Want to do that on iOS? There are UI conventions that match those requirements as well.
[grantcodes]I also think there is a bit of overlap in the ideas and critisisms here that isn't necessarily valid. If there is a "schema" of sort. That doesn't necessarily mean that clients have to become automatically generated, the two are not equal
gRegorLoveThe server returning the default is interesting, though with IBC I've been adding it as an account settings, so the UI will always default to that and can be changed per-post.
[eddie]or if you had a client that did listen posts, if it knew it was a private feed podcast, it could automatically default to sending private visibility as to not spoil the private feed
[eddie]One thing I like about the server sending default is that allows me to force a default based on client_id. So when approving IndieAuth, I could choose a visibility for that client and then all posts from that client could end up a specific visibility
[eddie]That is helpful, and I agree. It was an initial brainstorm and I think one nice thing that came out of it is grantcodes linked to some headless CMS APIs which are some nice prior art for how some existing platforms are doing this stuff.
[schmarty]The system was called FormBuilder and we wrote XML definitions that mapped onto Java Server Pages classes to create form entries and map them to database schema and relations.
[eddie]Also interestingly Micro.blog has been adding more fields and while I don’t think it should be required if Manton wanted to add support for other properties this is a page perfect for it. Accessed through a gear button is this page https://eddiehinkle.com/media/e9c4b22178ba8f7e00d05f9b58fc50c1.png
[schmarty]It honestly sounds a lot like what you're describing, haha, cuz we used it as a layer to make extensible testing websites to test other systems on.
[eddie][schmarty] That sounds like you have some good pitfalls experience. Obviously you might feel like "this shouldn't happen at all", but if you feel like you see a balance between "do it all the way" and "don't even touch it", I think those insights would be helpful
sknebelI considered a bunch of UI or microclients and some server logic to chain them too. E.g. have submitted posts default to private, but have a quick shortcut to change it's visbility or add permissions
sknebelI think aaronpk has a few of his editing things actually inline to the site (e.g. for tags?) but use micropub(?), but a link would be a start too
[eddie]once I do that, it's interesting to default posts to private since with the post list query, you could have as you said, mini clients that can query the existing posts and then edit some specific specialized attributes
aaronpki actually do that with quill blog posts most of the time. i have quill post as a draft to my site, then go use either my site's UI or hand-edit the file to do some final touch-ups before publishing
[eddie]sknebel: that's true. So your first client would take the url returned by the Micropub endpoint and pass that along to the next with something like ?url=postUrl
snarfedmaybe the main q for this group is, the webmention spec currently says discovery should "follow redirects," but doesn't say whether html meta redirects count. should it?
[eddie]I just think we might in general be upselling our current UI efforts (Indigenous for iOS absolutely included!). I think most of our current UIs could likely be generated by a schema form
[eddie]I don't think schema HAS to mean the UI is crappy, but of course if that's all you rely on, you'll never get a nice UI like Swarm. But I think there is a middle ground
[eddie]so if I have my server return these attributes and modify Quill to be able to support these items, does that count as real world example? If I don't change Quill's UI?
[eddie]But that's the point. Having some attributes for fields is not going to prevent good UI. Good UI being hard prevents good UI. All of our Micropub clients likely need a lot of work to get there
[tantek]devs who don't want to make good UI will make an awkward copy of someone else's good UI, which TBH in many cases is better than a generic crappy UI.
aaronpkI think there's another higher level thing here that I'm instinctively pushing back on, which is that these efforts regularly get criticized for trying to emulate existing social media behaviors but just distributed, and trying to then also do that in a generic templated way even further entrenches these apps in this mode
[tantek]there's also the downside that Micropub itself could get labeled as being to blame for the crappy UI, kinda like how CSS was blamed for crappy uncreative layouts until the CSS Zen Garden came along and opened people's eyes
[eddie]ahh gotcha. I guess for some reason you feel that having some attributes that help define some field behavior becomes "templated", but nothing says you can't break the template, but by having a few couple types of templated data allows for servers to provide data it might want returned.
aaronpkYeah it's a slippery slope thing. Of course you could make a nice product even with the templated JSON structure by not treating it as a declaration of the UI, but it's far easier not to do that, so will more likely than not result in not so great apps
[eddie]it is similar to the query for support properties, although @supports doesn't provide any contextual information about the css queries, where as we would need contextual information for Micropub properties
[eddie]I guess I just don't think the attributes we're discussing make it THAT much easier than it currently is to build a Micropub app, and thus wouldn't have much effect on the quality of Micropub apps (which are not horrible, but are also not pieces of art yet). and I think anyone that would be willing to put time into a Micropub app to make it really nice right now, would do the same thing regardless of having some JSON hints as to what type of dat
[eddie]Well, I'm heading out for the day. So you are free of this debate 🙂 I am absolutely not locked on the technical approach to this problem, but I do think the problem it's trying to solve is helpful and useful.
[tantek]I have a feeling we may be misunderstanding some key nuances. Maybe this would work better as part of an in-person Micropub brainstorming session?
[tantek]I do think there is more work to do in the general area of how do we evolve client and server capabilities in a manner which is backwards/forwards compatible and enables rapid iteration (co-evolution) of both.
[tantek]!tell eddie which next IWCs are you going to, and hopefully aaronpk is also going to and maybe you could propose a session on this and some of the challenges you've encountered with evolving your Micropub implementation(s)?
[eddie]I am hoping to go to Summit, but I have to finish arranging plans for a family trip before I see if it interferes with attending the Summit. I definitely think it ultimately is more around iteration of Micropub clients/servers than dictating UI, and you might be right, it is likely better a session at an IWC
Loqi[eddie]: [tantek] left you a message 3 minutes ago: which next IWCs are you going to, and hopefully aaronpk is also going to and maybe you could propose a session on this and some of the challenges you've encountered with evolving your Micropub implementation(s)?
[eddie]Thanks for that redirection tantek. I think it’s helpful and hopefully something that could be discussed at an IWC in the view of Micropub evolution rather than UI dictation
[kevinmarks] [aaronpk] - monocle ui suggestion - put the backlink into the title area for the channel rather than atop the content so you don't have to scroll back up to go back
[eddie] [grantcodes] If you are around I an very curious about your thoughts here: https://github.com/indieweb/micropub-extensions/issues/11#issuecomment-483658170 the idea of having some vague "not set" visibility seems really not user friendly. For a technical audience I think we can understand what "not setting" a property can do with the server defaulting things, but I don't know that a non-technical user base is going to feel comfortable with that.
[grantcodes] Yeah I was just about to comment but probably better here
[schmarty] like netlify CMS?
aaronpk Here's an example of where form generator territory falls on its face. Show me any modern app that lists the text "public" "private" "unlisted" in its UI. More often it's indicated by some sort of icon. Look at twitter and Swarm for easy examples. There's virtually no way to reliably do that in a way where clients can show that UI when they weren't written to support it natively
gRegorLove reads scrollback
snarfed so re the questions from last week, starting at https://chat.indieweb.org/dev/2019-04-11#t1555004634348000 ...
[tantek] aaronpk, this is my semi-irregular pitch for this fix/enhancement to webmention.io 🙂 https://github.com/aaronpk/webmention.io/issues/122
jacky I started looking into using https://indieweb.org/chat-names as a tool for vouch